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ABSTRACT 


Threat recognition and geographical training are fundamental parts of the 
requisite knowledge base for a large number of naval personnel who are assigned 
to operational or operations-oriented support billets. Yet readiness in these areas 
is often lacking, in large part due to the paucity of readily available, motivational 
instruction tools. 

This thesis explores major issues involved in integrating two emerging 
technologies, hypermedia and digital optical media (DOM), in the context of 
developing a prototype of just such an application: the GEOgraphic and Threat 
RECognition (GEOTREC) training and reference tool. The hypermedia software 
package used to develop the GEOTREC prototype, Hyperdoc version 1.12, gives 
evidence of the maturation yet needed in the integration of hypermedia and DOM 
technologies in application authoring tools. 

This thesis recommends the development of a system at least somewhat 
analogous to the GEOTREC prototype. Such a tool, using both hypermedia and 
DOM, would not only provide an enjoyable, intuitive, yet challenging way to 
foster multi-sensory learning, but also a quick, powerful, and easy-to-use reference 
to geographical and threat information needed for a myriad of operational 
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scenarios. 
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I. INTRODUCTION 


Training for U.S. Navy flight crews, Combat Information Center teams, 
ship’s lookouts, and Intelligence Center watchstanders in the areas of threat 
recognition and geographic familiarity is continually in need of enhancement. 
Threat recognition and geographical training are fundamental parts of the requisite 
knowledge base for these and other naval personnel who are assigned to 
operational or operationally-oriented support billets. 

And yet readiness in these areas is often lacking, in large part due to the 
paucity of readily available, motivational instruction tools. In addition, there is no 
single, effective, quick-reference source to which these personnel can go for timely 
geographic and threat recognition information in an operational environment. 

This thesis will look at a possible computer-based solution to these problem 
areas. It will study the use and integration of two emerging technologies, 
hypermedia and digital optical media (DOM), in the context of a specific 
operational application. That application, the GEOgraphic and Threat 
RECognition (GEOTREC) training and reference tool, attempts to provide a 
powerful, easy-to-use, didactic system to address these training and readiness 
shortcomings. This thesis will focus on the development of a prototype 
GEOTREC, using a specific hypermedia authoring software package, GECI 
International’s Hyperdoc, version 1.12. 
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This research represents an excursion into areas of technology and 
application about which much has already been written. It does not necessarily 
attempt to sail through uncharted waters, embody technological breakthroughs, or 
make dazzling discoveries. Rather, it explores the utilization of well-documented 
emerging technologies to meet operational requirements that exist now in today’s 
Navy. 

In order to do this, the thesis starts by examining the nature of these 
emerging and developing technologies and the major issues concerning their 
utilization and integration. First, Chapter 11 surveys hypertext and its logical 
extension, hypermedia. The chapter attempts to explain in lay terms the concepts 
and principles behind hypermedia, and to articulate its benefits over the linear 
presentation of information for certain applications. Following this, Chapter HI 
gives a brief overview of digital optical media (DOM), describing the capabilities 
and utility of this technology. 

Next, Chapter IV describes an application, namely the GEOgraphic and 
Threat RECognition (GEOTREC) training and reference tool, which integrates 
hypermedia and DOM into an ideal solution for the training and readiness 
shortcomings. This ideal GEOTREC was used as the model after which the 
prototype application was fashioned. Appendices A and B provide evidence of 
this GEOTREC prototype by respectively capturing a simple system 
demonstration, and providing the code generated in the system’s development. 
The prototype GEOTREC served as the basis of this thesis, providing a focused 
context for the study of hypermedia and DOM technologies. 
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The difficulties encountered in the development of the GEOTREC prototype 
are outlined in Chapter V. The chapter delineates the major obstacles, limitations 
and difficulties in developing and implementing these technologies in an 
application of this nature using the hypermedia authoring tools provided by 
Hyperdoc 1.12. Finally, Chapter VI offers the most salient conclusions and 
recommendations which have been engendered by the application of these 
technologies to the development- of the GEOTREC prototype. 
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II. HYPERTEXT/HYPERMEDIA 
A. WHAT IS HYPERTEXT ? 

Hypertext is a tenn encompassing a myriad of concepts, ranging from 
cognitive psychology theory to computer technology. In its broadest context, 
hypertext is based on a paradigm of the human thought process called 
associationalism which asserts that the mind functions in a series of associative 
leaps from one idea to another [Ref. 1]. 

From the earliest literature on hypertext (e.g., the July 1945 Atlantic 
Monthly article "As We May Think" by Vannevar Bush), much emphasis has 
been placed on the idea that hypertext stmctures data in a manner similar to 
human cognition; in particular, the organization of memory as an [sic.] 
semantic network in which concepts are linked together by associations. 
([Ref. 1], p. 129) 

In the more narrow context of computer technology, hypertext has been 
defined in The Computer Glossary as: "A technique that links information 
together. Words are invisibly linked to other words or explanations. For 
example, by pointing to a key word in a sentence and selecting it, the linkage is 
activated and the associated information is revealed." ([Ref. 2], Doc.#1522) 

A synthesis of these diverse hypertext contexts is provided in the 
introduction to the documentation for "HyperShell", a shareware hypertext 
software package. In that documentation, hypertext is aptly described as the 
application of computer technology to the presentation of information occurring in 
a non-linear form. The difference between linear information and non-linear 
information is characterized by the difference between a novel and a reference 
book. With a novel, a reader starts at page one and reads straight through to the 
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end, in a linear fashion. However, when a reader approaches an encyclopedia, 
dictionary, or other such tutorial book, he looks things up in an index, or table of 
contents, and follows references in certain parts of that book to other chapters, or 
even other books. It is this latter, non-linear type of literature and information for 
which computer-based hypertext applications are best suited. ([Ref. 3], p. 2) 

It is not at all easy to embody a full description of the hypertext concept in 
simple definitions. The following quotes are intended to provide an expanded 
understanding of hypertext: 

In a hypertext document, marked words or commands are doorways to 
information in other parts of the document, in other documents, or even in 
other applications. Reading a hypertext document is like playing hopscotch 
with ideas. Since each area or block of information may be linked to 
several others, you can jump around wherever your fancy takes you. That’s 
both the strength and weakness of hypertext. ([Ref. 4], p.l2) 

Think of a collapsible and expandable file alive with words, sound, 
animation, and photographs; that will someday become your basic hypertext 
document. Today,...existing hypertext programs let you affix electronic 
threads between words or pictures so you can grab a fistful of ideas in one 
place, in one sitting. ([Ref. 5], p. 76) 

The concepts of Hypertext are very old; they have been transferred to 
computer systems since the [19]60’s.... Originally intended to manage 
arbitrarily linked text segments, Hypertext has been extended to manage 
images and sound as well ("Hypermedia"). ([Ref. 6], p. 18) 


B. WHAT IS HYPERMEDIA ? 

The latter two quotations mention more than just text; they allude to the 
assimilation of other media into the hypertext arena, a technique often called 
hypermedia to indicate the expanded, multimedia scope. Once again, from The 
Computer Glossary : "Hypermedia refers to the use of data, text, graphics, video 
and voice as elements in a Hypertext system. All the various forms of 
information are linked together so that a user can easily move from one to 
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another." ([Ref. 2], Doc.#1522) Music, audio and other signals can be added to 
the above list. 

Although the term "hypertext" in its strictest definition pertains only to text, 
it is frequently used today to refer to the broader spectrum of information-linking 
in a variety of media, thereby encompassing "hypermedia" as well. Except where 
indicated, this paper will use "hypertext" in this larger, multimedia sense, treating 
the terms "hypertext" and "hypermedia" as virtually interchangeable. 

C. WHAT CAN HYPERMEDIA DO ? 

A graphically descriptive scenario for the use of hypertext is given in an 
article in the July 1989 issue of PC-Computing magazine. It asks the reader to 
imagine for a moment reading that magazine on a personal computer (PC) instead 
of on paper. When the "magazine file" is opened, the table of contents appears. 
Browsing through the headlines, the reader notices an article about hypertext, uses 
the mouse to place the cursor on the article’s title, and clicks on it. The article 
appears on the screen, describing how a major oil company is using hypermedia to 
keep track of its drilling operations. To find out more about how the company is 
using this new method of accessing information, the reader clicks on the oil 
company’s name. This activates an attached videodisc player, starting a video 
presentation, complete with music, highlighting the benefits of hypermedia to the 
company’s information needs. Following the video segment, the reader wants to 
learn where the company obtained their hypermedia system. A click on the name 
of the hypermedia vendor, and the screen displays an address, phone number, and 
product specifications. Just then, the doorbell rings, so the reader places a marker, 
and closes the magazine file. Thus, the next time he opens the electronic 
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magazine, the page where he left off is immediately available. ([Ref. 5], pp. 75- 
76) 

Multimedia applications of hypertext can provide an enormous amount of 
information to a user in a wide spectmm of vivid, captivating forms; 

In the context of a [hypermedia] video presentation, say, of an anatomy 
lesson, the collar bone can be displayed concurrently with data; click on a 
part of the collar bone on-screen and a short, technical description could 
appear. Other programs can use running text along with a videodisc 
presentation: On a two-monitor system, you see the film mnning by on the 
video display, while commentary scrolls along with it on your [computer’s] 
screen. You stop the videodisc, click on an annotation button, and more 
information comes up on what you’re viewing. In the digital world, sights 
become sounds, sounds become words, the word duck becomes a mallard 
flying across your screen. ([Ref. 7], p.lOO) 

Clearly, hypermedia applications provide capabilities for mfomiation retrieval 
never before possible with paper documents. Users can access multimedia 
information in the sequence, volume and format that best suits their needs at the 
time they access the information. In addition, they can change their access 
strategy each time they need to refer to that information. ([Ref. 1], p. 22) 

In addition to providing users with new capabilities, the authors, or creators, 
of hypertext applications can easily write (author) these applications for a myriad 
of multimedia uses. These include, but are by no means limited to ([Ref. 8], 
p.28): 


• Education and training; 

• Entertainment; 

• Travel; 

• Multi-language applications; 

• Real estate; 
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• Retail kiosks and information booths; 

• Landscaping, design and decorating. 

A March, 1989, article in Digital Review magazine reports how corporate 
and commercial designers are using HyperCard, a hypertext product from Apple 
Computer, to create impressive multimedia projects. These applications include 
live-action video and still images stored on laser disks, high-quality audio tracks 
for direct output from a CD player, and high-resolution color images, music and 
speech stored as computer data. The developers are also using color scarmers, 
music synthesizers, touch screens and other state-of-the-art input and output 
devices. Non-multimedia HyperCard applications are also popular with hypertext 
authors, and range from indexing large amounts of CD-ROM data to developing 

interactive tutorials and reference works. ([Ref. 9], p. 19) 

The capabilities of hypemiedia software have been largely unexplored until 
recent years. The reason for this reluctance in the past has largely been 
commercial viability: computer technology had not progressed to the point where 
such capabilities were affordable to a wide range of users in the marketplace. 
Even though advantages of hypertext have been evident for several decades, 
widespread interest in hypertext has been delayed until the supporting technology 
was cheap and readily available. ([Ref. 10], p.32) 

Today, however, the maturation of several of these supporting technologies 
appear to be converging to take advantage of hypertext’s offerings, particularly in 
the microcomputer arena: 

• Computer graphics and the Graphical User Interface (GUI); 
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• Digital Optical Media technology (e.g., CD-ROM, videodisc, WORM); 

• PC imaging systems which digitize photos, documents, etc.; 

• Optical Character Recognition (OCR). 

However, this "technology lag" may not tell the whole story of hypertext’s 
slow start. Many experts feel that something more than just technology had to 
change, namely computer users themselves. Today’s computer users more easily 
accept the role of the computer as a tool for processing ideas, words, and 
symbols, in addition to numbers and mere data. Their vision for the use of the 
computer as a vehicle of multimedia interhuman communication has greatly 
expanded beyond that of computer users of even just half a decade ago. ([Ref. 
10], p.32) 

D. WHAT CAN HYPERMEDIA NOT DO ? 

While hypermedia provides powerful tools for information retrieval and 
manipulation, it does not represent a breakthrough which will supplant traditional 
database models and systems. "HyperCard can’t do everything. It’s a great 
prototyping tool for indexing, creating interactive applications and training 
programs, and for multimedia work. But don’t try to use it as a substitute for a 
full-featured database program...." ([Ref. 9], p.l9) The warning is applicable to all 
hypermedia software. 

Perhaps the most significant limitation of hypermedia applications is that 
they rely on databases which aie pre-structured by the application author for one 
specific application. Such a database does not lend itself to easy use by other 
applications without a considerable amount of adaptation and reorganization (such 
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as creating a new "hyperdocument"; see section n.E. for more on 
hyperdocuments). This is especially true when multiple applications need to 
access the same database simultaneously. 

Moreover, hypermedia applications cannot satisfy a wide range of ad hoc 
queries. Take, for example, a hypertext cookbook application, using a database 
consisting of, among other things, textual recipes and digitized photographs of the 
prepared foods. A user could hypothetically navigate through the "hyper¬ 
cookbook" as follows: 


1. opening screen provides a breakdown by categories (e.g., "Appetizers", 
"Desserts", "Meats & Poultry", "Breads", etc.) — user selects "Desserts"; 

2. second screen provides dessert types (e.g., "Cookies", "Cakes", "Puddings", 
"Pies", etc.) -- user selects "Pies"; 

3. third screen provides specific pie selections (e.g., "Apple Pie", "Pumpkin 
Pie", "Boston Creme Pie", "Pecan Pie", etc.) -- user selects '^Apple Pie"; 

4. fourth screen shows the recipe, widi certain keywords highlighted (e.g., 
"apple", "crust", etc.), and a menu of choices which are standard on every 
recii^ screen, such as "Photo", "Measurement Conversions", "Microwave 
Version", and the like; 

5. the user then selects the highlighted word "apple" to get a more detailed 
explanation of apples (e.g., apple types, such as "Cortland", "Macintosh", 
"Granny Smith", etc.), with options like: displaying an image of each apple 
type on the screen; providing information as to which are best for bal^g, 
making cider, or eating raw; or even a short musical video clip of the 
adventures of Johnny Appleseed (for the kids, of course); 

6 . the user tlien returns to the "Apple Pie" recipe and follows the instructions, 
selecting "Measurement Conversions" and other such help items from the 
standard menu as needed; 

7. as the pie is baking, the user selects "Photo" from the standard menu, and 
then dreams about how the one in the oven is going to look even better than 
the image now on-screen... 
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While this hypothetical application obviously gives the user access to a great 
deal of information in an associative, intuitive manner, it does NOT permit 
complex, ad hoc, relational queries, such as: 

(a) give me the names of all recipes which: 

USE — main ingredients: "apples", 

AND “ spices: "cinnamon AND nutmeg", 

BUT NOT -- main ingredients: "sugar", 

AND HAVE - calories per serving: "< 300"; 

(b) list all "Photos" which: 

SHOW -- foreground elements: "apple pie OR 
pumpkin pie OR boston creme pie", 

AND “ background elements: "silver pie server AND 
cup of steaming coffee". 

In order to provide such functionality, a broad database built on the 
relational model is required. A major obstacle involved in developing and 
managing such a database is the unstructured nature of data types such as image, 
sound and signal. Research is currently underway at the Naval Postgraduate 
School in Monterey, California, into the mammoth task of incorporating the 
multimedia-handling features of hypermedia into the relational database model. 
One of the goals of this effort is to extend relational database management 
systems (DBMS) to manage multimedia databases, and to support numerous 
multimedia applications simultaneously. [Ref.s 6, 11, and 12] 

While not intended to supersede traditional database systems, most 
hypermedia software packages can act as a "front-end” to a relational database by 
allowing the user to link to a DBMS when appropriate. For example, if the user s 
query had to do with an automobile clutch, then the he would click on the graphic 
representation of the clutch on a diagram. A menu would pop up asking what he 
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wanted to find out about the clutch. If it was how to ichahge a clutch he would 
be routed to various static levels of explanation. However, if he wanted to find 
out dynamic information, such as how many clutches were in stock, ordered 
primarily by price and secondarily by part number, the hypermedia link to the 
DBMS would access a relational database. ([Ref. 13], p.l) 

hi addition to the above limitations, hypermedia does NOT provide a 
universal, all-encompassing solution to information storage, retrieval and 
presentation. For instance, "...not all texts are suitable for hypertext 
representation....[In fact,] experience suggests that if the document is closely 
interwoven through rhetorical devices, then decomposition into chunks and links’ 
will be difficult, with lose [sic.] of information and confusion of meaning a 
potential result. For some documents, this conversion is either impossible or not 
desirable because it destroys the subtle interconnections of theme, argument, 
metaphor, and word choice." ([Ref. 1], p.63). 

E. HOW IS HYPERMEDIA IMPLEMENTED ? 

The above discussion of hypermedia’s definition, capabilities and limitations 
would be incomplete without at least a brief exploration of how hypermedia is 
actually implemented in applications. 

As previously indicated, the creator of a hypermedia application is often 
referred to as its author. The author designs an application using the node as a 
basic building block. Each node consists of a single idea or concept. As the 
author thinks of new ideas, he can develop them into nodes and link them to 


' Section n.E. wiU further describe these hypertext chunks, or nodes, and the links 
that connect them. 
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existing nodes, or he can leave them temporarily isolated if making such 
associations would be premature. ([Ref. 10], p.38) 

The expertise required for authoring, from casual user to experienced 
programmer, depends both upon the nature of the application and upon the 
hypermedia package being used. There are many hypermedia software packages 
presently available for all levels of computing, ranging from text-handling-only to 
full multimedia. Host systems range from Macintosh or IBM-compatible 
microcomputers to large mamframes. A broad sampling of existing hypertext 
packages includes; 

• HyperCard (Apple Computer — for Mac/OS) 

• SuperCard (Silicon Beach — for Mac/OS) 

• Guide (Owl International — for Mac/OS, MSDOS) 

• HyperShell (shareware by Text Technology -- for MSDOS) 

• KnowledgePro (Knowledge Garden - for MSDOS) 

• LmkWay (IBM - for MSDOS, OS/2) 

• Hyperdoc (GECI International - for MSDOS, UNIX) 

• Topic (Verity - for MSDOS, OS/2, VAX/VMS, and UNIX) 

• Intermedia (Brown University — for UNIX, Mac/OS) 

There are, at a minimum, three basic components of any hypertext 
application: 

1. a means for the user to interact with the application, normally a graphical 

user interface (GUI), i.e., menu-driven and mouse-oriented, as opposed to 

command-line-entry; 

2. a database consisting of elements, or nodes, of relevant infomiation; and. 
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3. active cross-references, or links, between the nodes of that database. 

The combination of nodes and their connecting links form a hypertext network, 
commonly referred to as a hyperdocument. This hyperdocument is the file or 
collection of files which serves as the blueprint of the hypertext application, giving 
the online information its structure and connectivity. ([Ref. 1], p. 61) 

Each hypertext package provides a variety of tools with which the author can 
build an application. These range from embedded text editors or word processors 
(or the ability to import files created with separate word processing software), to a 
myriad of menu-driven tools, to the incorporation of macro-commands (macros) 
and even source code which is written in third and/or fourth generation 
programming languages that the package will compile. New authoring tools are 
continually being developed: 

A paradoxical symbiosis exists in all of this. Apple and other [hypertext 
software package] developers cannot provide users with tools until users 
themselves have determined what it is they want to do, while users need 
tools to discover what’s possible. As with all innovation, it’s a process of 
education. Providing more linking capabilities will lead us to providing 
users with additional tools to better understand more concepts. How do 
people work with hypertext, hyperauthoring? The number of people that 
have reasonable answers to this stuff is very limited... ([Ref. 14], p.l8) 

Using appropriate tools, an author begins by establishing, in the first node of 
the hyperdocument, the general subject areas in the application’s database. This 
acts much the same as a table of contents in a book, and will normally constitute 
information and selection options that will appear to the user on the opening 
screen, or frame. From these starting points, the author can build a network of 
links between associated nodes as he wishes, both downward, as in a hierarchical 
tree structure, and/or sideways, as in a network data model. In this way, the 
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application’s user can select and follow whichever series of links he chooses 
within constraints of options specified by the author in the hyperdocument. 

These links are not hmited to tying nodes of the same hyperdocument to one 
another. One of the more powerful features of many hypertext packages is the 
so-caUed hot link. A standard hypertext link connects information within the same 
application; by contrast, a hot link allows the user to access information in other 
applications. Hot links could be used to connect such diverse applications as, for 
example, a Lotus 1-2-3 spreadsheet, a video presentation, an animation sequence, 
and, as mentioned before, a relational database. 

Full capabilities of hot links are still under development. For instance, a hot 
link can be forged to a specific file, but cannot be defined to link to a specific 
place in that file. The user cannot yet use hot links to jump to a specific cell in a 
spreadsheet, or have a variable in a hypertext report automatically updated when 
that same variable is changed in the table of a relational database package such as 
Oracle, Ingres, or Paradox. This capability is coming, however; experts in the 
field speculate that, within the next five years, almost all hypertext programs will 
allow the author to easily create such sophisticated hot links. ([Ref. 4], p.l2) 

In addition to these components, hypertext applications often need a means 
of keeping track of where the user is "located" in this network of Unked ideas at 
any given time. K the application is anything but very small, the user can easily 
get disoriented, particularly if he wants to return to an idea (a screen, menu, node, 
frame, etc.) previously encountered. Most applications allow the user to navigate 
around the hyperdocument using a "road map", known as a browser, which 
displays the network graphically, indicating the user’s position. 
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The browser is an important component of the larger, more complex 
hypertext systems. Its display of some or all of the hyperdocument as a graph 
provides "an important measure of contextual and spatial cues to supplement the 
user’s model of which nodes he is viewing and how they are related to each other 
and their neighbors in the graph," ([Ref. 10, p. 19) 

Due to the nature of hypermedia, authors can develop applications with 
broad utility and appeal. Because so many forms and sources of information can 
be Unked together, an application can be easily written for a wide range of 
expertise without confusing the novice or boring the expert. Each reader can 
pursue a topic to the depth that is most appropriate to his or her needs. This 
allows the hypertext author to use high-level concepts terminology; novices can 
click on any unfamiliar terms in order to learn about them, while more 
knowledgeable readers can move ahead to more advanced topics. ([Ref. 4], p.41, 
and ^[Jtef.'!], p. 124); 

ake, for examplfe, an application deatmg with aviation-related training. The 
key personalities, aerodynamic concepts, and acronyrhs of the trade could simply 
be mentioned without further description for the sake of mote advanced users. At 
the same time, other readers could click bn those key terms and follow the links 
to the data in related nodes if they need further explanations, help or background 
material. 

In summary, hypermedia has moved in just the past five years from largely 
theoretical and experimental concepts to highly useful and commercially available 
real-world applications. Within the bounds of inherent limitations, some of which 
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have been discussed in this chapter, its potential appears to be enormous and 

could strongly impact the way users interact with information: 

...the greater sense of control over the reading process may produce 
increased [reader] involvement and the desire to read more. In the same 
way that computer games can be very absorbing because of the high level of 
interactivity, hypertext databases may be very engaging too. ([Ref. 1], p. 
129) 
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in. DIGITAL OPTICAL MEDIA 


A. BACKGROUND 

Binary digital data -- information encoded into zeros and ones for computer 
processing ~ can be stored in many forms and on a variety of media. In the late 
1960s and 1970s, magnetic tape, somewhat similar to that used on standard tape 
recorders, was perhaps the most prominent medium for mass storage of digital 
data. In the late 1970s and 1980s, the use of magnetic disk became widespread. 
A different category of media, one that is non-magnetic, has emerged from 
research laboratories and into increasingly greater public use: Digital Optical 
Media (DOM). 

Digital Optical Media (DOM) are also know as optical laser (or even laser 
optical) media. (For simplicity and ease of reference, the remainder of this paper 
will use the "DOM" abbreviation to refer to this category of media, and will use it 
as if singular, even though the last term in DOM, "Media", is actually plural). 
Whichever terms are used, they refer to any media in which the information is 
first converted to binary digital form, and then into its recorded form by use of an 
optical laser (Light Amplification by Stimulated Emission of Radiation). To read 
the data, the process is reversed: the recording is read by a low-powered laser, 
converted ir^ binary digital form, and then into whatever form is appropriate for 
an application. ([Ref. 15], p.71) 

The first commercially prosperous DOM was the audio Compact Disc, or 
CD, the familiar shiny-silver disks, just under five inches in diameter, which are 







quickly replacing vinyl record albums in the music recording industry. Somewhat 
less successful has been the Compact Disc Video (CDV), more frequently called a 
videodisc or laser disk. These look similar to CDs, but are 12 inches in diameter, 
and normally store a feature-length movie as well as its soundtrack in digital form. 
Both of these DOM have been commercially available in meaningful quantities 
since the early to mid-1980s. 

Only relatively recently has the optical disk technology behind CD and 
videodisc been applied with a significant degree of success to the computer field, 
outside of the entertainment industry. DOM was initially applied there to meet 
largely static mass data storage requirements such as those found in libraries, 
archives, technical manuals, legal records, and the like. Today, however, the 
"buzzword" application for DOM is multimedia. As previously described in 
Chapter Two, this multimedia (sometimes called Digital Optical MultiMedia, or 
DOMM) consists of data, text, sound, images, graphics and video all stored in 
digital format, and on the same disk. 

B. GENERAL ADVANTAGES OF DIGITAL OPTICAL MEDIA (DOM) 

Part of the attraction of using DOM for both mass storage and multimedia 
applications is that it "delivers many bytes in a small volume (high storage 
density), attains low error rates (high fidelity), and can be replicated rapidly in 
large numbers at a modest cost (economy)." ([Ref. 15], p.68) 

Consider storage capacity. Each CD-ROM (Compact Disc-Read Only 
Memory) - cuirently, the most common form of DOM - has an effective track 
density of 16,000 tracks per inch, with a mere 1.6 micrometers separating each 
track. In contrast, 5.25 inch floppy disks, despite being larger than CD-ROMs, 
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have a density of only 96 tracks per inch. ([Ref. 16], p.27) Due to this density, a 
CD-ROM can store up to 680 megabytes of digital data — over 560 times as 
much data as a high density 5.25 inch floppy disk, ([Ref. 17], p.l7) Such 
gargantuan storage capacities are shared by other types of DOM, as well: 
Eastman Kodak Company manufactures a 14 inch optical disk that can hold 6.8 
gigabytes (i.e., 6.8 billion bytes) of data; if the data on just one such disk were 
text, and that text was printed on paper, nearly 275 file cabinets would be required 
for storage space! ([Ref. 16], p.25) 

Another clear advantage of DOM is that it is much more durable than 
magnetic media. Read-only optical disks consist of a base, or shell, made of a 
light, durable plastic which is covered with a thin reflective layer (normally 
aluminum)^ The data are represented on the reflective layer by a series of pits 
(depressions) and lands (the flat surfaces between pits). When the disk is rotated, 
and then illuminated, Or read, by a low-powered laser, the lands reflect back more 
light than the pits. A change in the reflected light caused by movement from one 
level to the other (pit-to-land, or land-to-pit) is translated as a binary one; no 
change in the reflected light (pit-to-pit, or land-to-land) represents a binary zero. 
For illustration, a series of binary digits such as "1110 0100" would be written to 
the disk as: "land-to-pit, pit-to-land, land-to-pit, pit-to-pit, pit-to-pit, pit-to-land, 
land-to-land, land-to-land". Once the data to be stored are transcribed onto the 
disk as pits and lands, the disk is coated with a hard, resilient, clear lacquer. 


^ This does not fully apply to WORM or M-O disks, as will be discussed later in 
this chapter. 
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Due to this durable lacquer coating, DOM is generally more secure than 
magnetic media. Because altering the data on a read-only optical disk or a 
WORM disk requires some form of physical destruction of the medium, the stored 
data cannot be easily tampered with, intentionally or unwittingly damaged, or 
inadvertently erased (an M-O disk provides the same data security, when not in 
the presence of the high-intensity write laser contained in the M-O drive). And 
because tiiere is no physical contact between the laser and the disk, the medium 
does not get worn with time and usage. 

In addition, DOM is virtually impervious to magnetic fields, normal climatic 
conditions or changes (e.g,, high humidity, reasonably cold temperatures, etc.), and 
even some dust, dirt, or minor scratches. By contrast, magnetic media are more 
or less vulnerable to all of these. Finally, most estimates indicate that optical 
disks should last at least 30 years with normal usage, and may even last up to a 
full century. Most magnetic media, on the other hand, are considered reliable for 
just three to five years. 

C. DISADVANTAGES OF DIGITAL OPTICAL MEDIA (DOM) 

DOM is clearly not appropriate for every application. Because of the 
permanent nature of read-only optical disks, they should not be used for data that 
are frequently changing and in need of updates; WORM and M-O disks can be 
used in such applications, but in many cases a hard disk or Bernoulli box would 
work better. 

In addition, errors introduced prior to the manufacture of a read-only optical 
disk are as permanent as the media. Such errors could include anything from 
typographical errors in the text of a technical publication, to incorrect colors in 
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graphical images of the national flags of past World Cup Soccer champions. 
Although the chances of introducing errors during the actual optical disk 
production are minuscule^ complete and thorough scrutiny of die data during pre- 
mastering is essential to ensure an error-free final product. 

Another drawback for DOM is its inherently slow operating speed relative to 
magnetic media such as hard disks. A CD-ROM, for instance, has an average 
data transfer rate of 150 kilobytes per second, as opposed to a typical hard disk 
with data transfer rates of 700 kilobytes per second or more. In addition, CD- 
ROM access speeds can average from one to ten seconds, as opposed to hard 
disks whose access times are measmed in milliseconds. Because of these slower 
speeds, DOM is generally not useful for tmly "real-time" applications. ([Ref. 17], 
p. 17; and, [Ref. 18], p. 14) 

D. MAJOR TYPES OF DIGITAL OPTICAL MEDIA (DOM) 

There are three major types of DOM in use in the computer industry today: 

1. Read-only optical disks, including: 

a. CD-ROM (Compact Disc-Read Only Memory) 

b. Videodisc (Compact Disc Video (CDV), or laser disks) 

2. WORM (Write Once, Read Many) disks 

3. M-O (Magneto-Optical) or E-O (Erasable Optical) disks 


^ The error detection and correction techniques available today can reduce the 
chances of a system-introduced error to virtually zero; for example, the error detection 
techniques used in the Data Defense Network (DDN) provide an expected undetected 
error rate of 4.2 * 10 '®, meaning that if a user sent a full message packet (8,063 bits) 
over the network every second of every hour of every day, a bit error would slip 
through undetected only once every one million years! (Taken from p.7 of a 1984 
Defense Communications Agency brochure entitled, "DDN Defense Data Network".) 
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This is not meant to be an exhaustive list of DOM. For instance, read-only 
optical disks come in a wide variety of sizes besides the 4.7 inch CD-ROM and 
the 12 inch laser disk, including diameters of 5.25, 8, and 14 inches. However, 
the types listed above represent the major areas of DOM research, development 
and marketing today. Each of these forms of DOM has specific advantages and 
disadvantages; each is appropriate for specific and differing applications. 

1. Read-only optical disks 

Read-only optical disks are characterized by their permanence of data. 
Their forte is information dissemination. "The whole purpose of [read-only DOM] 
is mass distribution. Like books, magazines, microfiche, CD-Audio discs, LP 
records, and other mass distribution products, the actual...discs are produced in 
quantity at a replication facility." ([Ref. 19], p.34) While other types of DOM are 
just as suitable -- and in many applications, more suitable — for mass data 
capturing and storage, they are not as useful as read-only DOM for the publishing 
of digital information. 

a. CD-ROM (Compact Disc-Read Only Memory) 

CD-ROM is indisputably the most common format of DOM in use 
today. It has been successful in large part due to the early acceptance of 
standards by almost all CD-ROM manufacturers. But, perhaps as much as 
standards, size has played a major role in this optical disk format’s success. At 
just 4.7 inches (120mm) in diameter, this small size, together with light weight 
and durable construction, make for convenient handling, storage, and 
transportation. This portability translates directly into lowered costs for almost all 
phases of CD-ROM creation and use. 
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These factors imply that CD-ROM is superior at least to paper and 

floppy disks for mass storage and dissemination of textual data, and give strong 

reasons for its steady growth in such application areas. But CD-ROM is 

becoming the medium of choice for multimedia applications as well. In fact, 

there are two competing standards for CD-ROM multimedia applications: DVI 

(Digital Video Interactive), and CDI (Compact Disc Interactive). 

With a CD’s vast digital data storage capacity, multimedia on a personal 
computer [is] now within reach. This is indeed the idea behind CD-I and 
DVI....Combine the high-fidelity soimd of compact discs, add still images 
and/or moving pictures, supercharge it with microprocessor horsepower, and 
the result is an interactive multimedia library. ([Ref. 8], p.28) 

DVI (Digital Video Interactive) technology involves compressing 

multimedia data onto a CD-ROM, allowing up to an hour of video, audio, 

graphics and other information to be stored on a single disk (without such 

compression, a CD-ROM could hold only 30 seconds worth of digital video). To 

play back the images on a PC (personal computer), the CD-ROM player reads the 

data, sends them to the PC, and the DVI software decompresses them, sending 

over 30 images to the screen per second. ([Ref. 18], p.l4; and, [Ref. 20], p.l6) 

CDI (Compact Disc Interactive) has similar data compression 

success, but uses the Motorola 68000 microprocessor insidie the self-contained CDI 

player to decompress the data. The CDI player, which comes with its own 

remote-control and joystick, can be plugged directly into a standard television 

and/or stereo equipment, in addition to a computer monitor, to provide the 

interactive presentation of video, audio, text and other data. ([Ref 18], p.l3; and, 

[Ref 20], p.l6) 
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b. Videodiscs 

With the exception of its larger size (12 inches in diameter, vs. the 
4.7 inch CD-ROM), the videodisc is similar to CD-ROM in most respects. 
Ironically, it is the videodisc’s larger size that is both a major advantage and a 
major disadvantage vis-a-vis its smaller counterpart. While the larger size detracts 
from the laserdisc’s handling convenience, it does provide a significantly storage 
capacity: an optical videodisc can hold up to 54,000 images, with an access time 
as fast as one to two seconds for a single frame. ([Ref. 21], p.l03; and, [Ref. 12], 
p.ll) Despite CD-ROM’s popularity, the videodisc will maintain its niche in the 
optical storage world, a position that could well strengthen as more and more 
applications demand storage capacities beyond those that can be reasonably met 
using CD-ROM. 

2. WORM (Write Once, Read Many) Disk 

WORM disks fill another special niche in the world of DOM. They are 

best utilized for applications which receive new data on a routine, periodic basis, 

but which require the old data to be retained, rather than over-written. 

[On a videodisc], each document, record or image has an address for use in 
later retrieval of the data. Although the recording of data is permanent, the 
address of a former document may be updated, directing the retrieval 
program to locate a newer, more recent version. ([Ref. 19], p.34) 

Like other optical disks, a WORM disk is made of multi-layered 

materials. To write on a WORM disk, a high-intensity laser is used to heat and 

permanently alter the information-holding layer, so as to change the way it reflects 

the light from the low-powered laser used to read the disk. This recording is done 

on the disk by the WORM drive as needed, until eventually, when the WORM 
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disk is filled, a new, blank disk is inserted so the continual recording of data can 
resume. ([Ref. 16], p. 31) 

3. M-0 (Magneto-Optical) or E-O (Erasable Optical) Pisk 

Digital data on erasable optical disks can be written and erased, updated 
and modified, retrieved and manipulated in a similar fashion to other writable 
storage devices, such as hard disks, Bernoulli cartridges and floppy diskettes. The 
disks are made of multi-layered materials arranged horizontally in thin wafers. 
The outer layers are hard and transparent, much like the lacquer on other optical 
disks,^^ ^ T^ however, contains particles which can be magnetically 

oriented up or down, but only when the medium is heated by a strong laser. 

To write on the disk, the laser heats specific points of the inside medium, 
and the drive then magnetically re-orients the particles in those specific points. 
The center layer then hardens as it cools back 4own» maintaining the particles in 
their alteretl orieritations. When reading from the disk, these particles reflect the 
light from a low-powered laser according to their orientation (up or down), in 
much the same way as the pits and lands of a read-only optical disk. ([Ref. 16], 
p.32) 

M-O disks are most attractive for applications in which the data are 
somewhat static. In such applications, the information being stored needs to be 
changed and updated intermittently, but, in between updates, it needs the security 
and storage capacities offered most cost-effectively by DOM. 
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IV. OPERATIONAL APPLICATION 
A. BACKGROUND 

A primary goal of this thesis research was to determine whether optical laser 
technology and hypertext/hypermedia techniques can be combined and applied in a 
reasonable manner (logically, technically, financially) to a specific operational 
application. The context of an operational application was used in order to 
maintain a central focus for the study. That operational application is the training 
and readiness of U.S. Navy personnel in the areas of threat recognition and 
geographic familiarity. 

The training of U.S. Navy personnel in the areas of threat recognition and 
geographic familiarity is continually in need of enhancement. A host of Navy 
jobs require a sound knowledge of threat units and their capabilities. This 
knowledge must be constantly refreshed, in both visual recognition and mental, 
factual recall dimensions. This knowledge must also include familiarity with 
friendly and neutral platforms, in order to separate them from true threats. 

Personnel most in need of such training include Navy flight crews. Combat 
Infonnation Center watchstanders, ships’ lookouts (including "Snoopy Teams"), 
Bridge teams, and Intelligence analysts. These personnel must be able to instantly 
recognize threat platforms from a glimpse, seen from almost any angle, and often 
under conditions of poor visibility and at great distance. Not only must visual 
recognition be immediate, but so must be the recall of pertinent facts about 
capabilities such as operating speeds and ranges, weapons carried and their 
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effective ranges, and the like. The timeliness and accuracy of such recall could 
potentially, in a hostile scenario, be a matter of life and death, of victory or 
defeat. 

In a similar manner, almost all of these same personnel require familiarity 
with the geographical operating environment. A knowledge of relative locations 
of open seas, islands, chokepoints, contiguous nations and their territorial waters, 
operational bases and aufields, restricted areas, standard operating areas, and such 
is crucial to safe, effective and successful mission planning and accomplishment. 

In addition to training m these areas, there exists the need for a single, 
effective, quick-reference source to which these persoimel can go in operational 
situations to get timely geographic and threat information. This reference source 
must be readily available, easy to use, readable, responsive, accurate, up to date, 
and flexible enough to answer users’ queries in the format or formats of their 
choice. It must accept, tie together, and then cohesively present information taken 
from a wide variety of sources, and information occurring in a variety of media, 
including textual, visual, and amal. 

B. HOW IS IT CURRENTLY DONE ? 

Geographic and threat information is currently found in a plethora of disjoint 
sources. Unwieldy paper publications, maps and charts, photographs and 
drawings, 35mm slides and overhead projector viewgraphs, projectors and 
videotape players and the like are the primary reference and training tools in use 
today. These resources are largely manual in nature, often leading to laboriously 
slow, inefficient information retrieval and manipulation, hi addition, they are 
often not centralized, requiring users to go to various locations to have access to 
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the proper equipment, and to physically collate and coordinate the tools and 
information for use. 

Due to the wide variety and availability of current resources, there is no 
standardization, often resulting in incomplete training, "holes" in information 
reliability, and varying degrees of readiness among user organizations. For 
example, if the first unit of a new class of submarine becomes operational in the 
naval forces of a particular nation, an organization must update each of their 
reference publications that include submarines individually. Frequently, there is a 
waiting period of months before the change is provided as a formal change-issue 
from the publishers. In addition, new slides and photographs of this class of 
submarine need to be produced, normally drawn from sources such as commercial 
defense-related magazines and publications, with the organization able to use only 
those sources that are immediately available to them (which are extremely limited, 
for instance, when out to sea). 

Currently, the training process occurs most often in the form of briefings, 
lectures, slide presentations, and training sessions led by Intelligence Officers, 
Specialists, and collateral duty sub-specialists. Due to the nature of the material 
and the required knowledge levels, these training sessions can become tautological 
and mechanical, drilling the attendees over and over until the material becomes 
ingrained. In other circumstances, the material can be rushed, or presented at a 
"fire-hose" pace which only a few of the trainees can maintain; the rest retain only 
as much as they can "swallow”, and the bulk of the information flow' washes 
ineffectually away. Because of the current limitations on infonnation presentation. 
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the trainees receive training which is not individually-tailored, which cannot be 
self-paced, and which can sometimes be repetitious, inconsistent and/or ineffective. 

In addition, this training requires many man-hours to prepare and conduct. 
The instructors must often divert their efforts away from their primary duties, such 
as intelligence analysis and reporting. For instance, almost all Naval aviation 
squadrons are assigned at least one InteUigence Officer. Some squadrons, 
especially tactical aviation (TAGAIR) squadrons such as Helicopter Antisubmarine 
(HS) and Light Attack (VA) squadrons, need such an officer for very little other 
than to teach threat recognition to the flight crews. While this is no insignificant 
task, it is not a fuU-time job; consequently, the inteUigence officer is not used to 
his full potential in his intelligence role, and is often burdened with a myriad of 
collateral billets which hinder his participation in and contribution to Carrier 
Intelligence Center (GVIC) and related activities. 

C. HOW SHOULD IT BE DONE ? 

It IS hereby proposed that the combining of several existing technologies into 
an interactive computer-based system could meet these aforementioned 
shortcomings. One system could act as both an integrated, multimedia training 
tool, and as a centralized, easy-to-use geographic and threat information reference 
tool. For simplicity, this system will be called the Geography and Threat 
Recognition (GEOTREC) Training and Reference Tool, or GEOTREC system for 
short, throughout the remainder of this paper. 

Consider first an ideal GEOTREC system, which would be developed if time 
and money were not major factors, and if existing/developing technologies were 
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easy to mix and match. Such a system would have capabilities similar to those 
described in the following paragraphs. 

1. Major Features: 

The major features of the GEOTREC system would include, but would 
not necessarily be limited to: 

• Viewing (still photographs, three-dimensional line drawings, annotations, 
overlays) 

• Geographical Plotting (maps, charts, overlays) 

• Unit Identification (in a Query/Response format) 

• Training (point-and-ask, random-viewing quiz, score-keeping) 

• Gateway to a relational, multimedia database 

Each of these features will be described in more detail in the paragraphs 

below. 

2. Outputs 

Although it can seem somewhat backwards and counter-intuitive, it is 
often most helpful to describe a computer system by detailing its outputs before 
examining its inputs. The ideal GEOTREC system would provide multimedia 
outputs of at least the following types: 


• textual, descriptive information relating to threat and friendly platform 
characteristics, capabilities, order of battle, background information, historical 
trends, and such; 

• digitized maps and charts, in a format which allows for user-selectable 
scaling and zooming (i.e., the user can point to and mark a spot on the 
presently displayed chart, and then zoom in or out with that spot becoming 
the display’s new center point), and also allows for user selection of chart 
type (e.g., road map. Tactical Pilotage Chart (TPC), ocean floor topography 
chart, map showing political boundaries, or whatever); 
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• digitized photographs and rotatable three-dimensional line drawings of threat 
and friendly platforms (ships, submarines, aircraft), weapons systems 
(missiles, launchers, bombs, guns), sensors (radar, sonar. Electronic Support 
Measures [ESM] and Electronic Countermeasvues [ECM] equipment), and the 
like; 

• overlays consisting of user-generated annotations, highlightings, hypothetical 
scenarios, and other such markings, to be used, for instance, for briefings, 
reports, comparison and historical analysis; these annotations could be 
overlaid by the user on any of the digitized maps, charts, photographs, or 
drawings; 

• motion video, showing actual footage of such things as threat and friendly 
units underway/inflight, or even panoramic views of approaches to certain 
landmasses or coastal areas taken from various angles and/or distances; the 
video would be capable of being stopped by the user at any frame for 
viewing as a still image; 

• an interactive knowledge base of threat unit features and characteristics 
which could be systematically queried/answered, in order to, for example, 
match a real-world contact Aat was sighted but could not be positively 
identified with a unit stored in the threat database (e.g.: the system would 
prompt, "Did the observed unit have a two-barrel gun turret?"; if responded 
to affirmatively, the next question might be, "Was the gun turret located 
forward, aft or amidships?"; a response of "aft and amidships" would cause 
the system to retrieve and display, for user scrutiny, pictures of only those 
units which have two-barrel gun turrets in those locations; and so on). 


3. Inputs 

The GEOTREC system would receive two major types of inputs; 
interactive inputs which users would enter on a routine basis, and baseline inputs 
entered by the system administrator on an as-required basis. Interactive inputs 
include such information as user name and user identification number for system 
logon, and responses to system prompts, indicating which commands and 
selections are to be invoked. 

Baseline inputs are those which update and add to the existing 
information base. They include: new maps, images or video clips added to the 
system’s repertoire, either via receipt of new CDs or videodiscs, or via an image 
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scanner, scanning images onto hard disk or WORM disk; maintenance of hnks 
between related nodes of information; corrections and additions to the textual 
portions of the system, such as the background and historical data, specifications 
and statistics, etc.; and updating of the tables in the relational database. The 
system administrator would be responsible for adding these inputs to the system in 
a timely manner, while verifying their accuracy, integrity and proper classification 
to the best of his ability. 

Baseline inputs such as CDs and videodiscs would be created and 
distributed by the national intelligence community and other agencies. Such 
sources would include the Defense Mapping Agency (DMA) which currently 
produces a wide range of digital optical media products, the Defense Intelligence 
Agency (DIA), the Naval Technical InteUigence Center (NTIC), and the two Fleet 
Intelligence Centers (FICPAC and FICEURLANT). 

4. Hardware and Software 

The best type of CPU, monitor, and other primary computer hardware 
on which to base such a system is uncertain. At the very least, the hardware 
should be fast (e.g., 25Mhz clock speed), have a large amount of active memory 
(RAM), and a large-capacity Direct Access Storage Device (DASD) such as a 
100Mb hard disk. A workstation with a high-resolution monitor, or perhaps even 
a powerful MS-DOS or Macintosh system would be needed. 

In addition, a fairly explicit suite of peripherals would be required to 
support the multimedia functionality. These would include at least: 

• videodisc player 

• CD-ROM player 
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• image scautiner/digitizer 

• WORM drive 

• full-color graphics capability (e.g., VGA caid/monitor) 

• laser printer 

Beyond the operating system and other standard system software, the 
required software for such a system would include, at a minimum - 

• Hypertext orchestrator 

• Special device drivers for the various peripherals 

• Relational DBMS (Database Management System) package 

• Gateways (to DBMS, other application software/systems such as FULCRUM, 
etc.) 

5. User Interface Scenarios 

For what purposes and in what ways would users interact with the 
GEOTREC system? The system could well be used for many things, and to 
answer many questions. The following are the major functions that can be 
presently envisioned. 

a. Self-paced Training 

The ideal GEOTREC system would allow each user to conduct 
training at the pace and level of detail most suited to his individual needs. During 
such a training session, the user could: 

• study individual geographical regions or threat units by viewing digitized 
maps, photographs or three-dimensional line drawings stored on videodisc, 
CD-ROM or WORM disks; these images would be fully annotated, labeling 
major land formations, national boundaries, etc., or visible weapons, sensors, 
and mnemonic features (annotations could be toggled on/off for non-cluttered 
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viewing); they would also be zoomable, to allow the user to look more 
closely at a specific feature; 

• watch video clips stored on videodiscs or CD-ROM which show actual 
footage of units maneuvering, submerging, taxiing, and the like, or what the 
coastal areas and sea lanes look like from the bridge when passing through a 
specific strait; in addition, the user could stop the video on any frame for 
viewing as a still image; 

• point the cursor to a specific feature of the map or unit being viewed (the 
imit image could be either a photo, line drawing or "frozen" video frame), 
click the mouse button, and receive a window-full of textual information 
about that feature, and/or have the system show a specific, more detailed 
image of just that feature; 

• probe deeper into the information on that unit or one of its features, to view 
specifications and order of battle information, or read background 
information, such as how that specific class of unit fits into the broader 
naval strategy of the nation that developed it, or historical analysis about the 
past operations of such units, standard operating areas, etc.; 

• ask the system to randomly call up non-annotated digitized charts or 
photographs of units for self-quizzing purposes, with the system asking for 
responses (e.g., an arrow points to a specific radar on a ship and the user is 
asked to identify the radar type — upon a correct response, the system moves 
tlie arrow to a specific missile launcher and asks again); the system would 
provide correct answers when given a wrong response, and could even 
tabulate a score based on responses. 


b. Quick-reference 

The GEOTREC system would also provide a single-source, quick- 
lefeience system to quickly answer questions arising in an operational setting. 
Some example scenarios follow to provide a clearer sense of how this might work. 

(1) Intelligence Analysis Scenario. An Intelligence analyst 
receives a report that a source has spotted a patrol boat passing through a 
particular chokepoint. The patrol craft was reported to have coffin-like missile 
launchers aft, and was flying an ensign composed of mostly gold and red colors. 
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The analyst first uses GEOTREC’s geographic features to find 
the chokepoint, and to see if the unit is entering an area of operations of concern 
to friendly forces. He simply enters the latitude and longitude given in the report, 
enters the width (in nautical miles) he would like the on-screen display to cover, 
and receives a display of that area of the world, centered on the given lat/long. 
From this, he determines that the patrol boat is en route an area where friendly 
forces are currently located. 

The analyst then selects GEOTREC’s gateway to the relational 
database. Using the database management system (DBMS) that GEOTREC has 
linked to, he queries the database for all naval ensigns of area nations which have 
at least gold and red as colors. GEOTREC responds with only one possible 
ensign, pinpointing to which nation the patrol boat belongs. 

The analyst then uses GEOTREC’s textual information features 
to get a listing of all naval units operated by that nation. From this, he narrows 
down the list of possible patrol boat classes to three. Then the analyst clicks on 
each of those three particular patrol boats, one by one, to view an image which he 
compares to the source’s description of the missile launchers until a match is 
made. The analyst can then report the contact with increased certainty, allowing 
appropriate action to be taken by friendly assets in that operating area according to 
the degree of the known threat posed by the now-identified unit. 

(2) Tactical Action Officer (TAO) Scenario. A Tactical Action 
Officer (TAO) in a ship’s Combat Information Center (CIC) receives a message 
which indicates that aircraft of a particular type are airborne, and heading toward 


36 






























the ship. Using GEOTREC’s unit viewing function, the TAG selects from a menu 
(or types in at the command line) the class of aircraft mentioned in the message. 

The system quickly displays a photograph of that class of 
aircraft, with menu options to view specifications (such as maximum speed of the 
aircraft, inflight refueling capabilities, etc.). The TAG clicks on the missile shown 
being carried under the aircraft’s wing in order to receive more information about 
its capabilities (e.g., maximum effective range). The TAG now has on-screen and 
at his fingertips the information necessary to make decisions relating to the ship’s 
defensive posture and other such actions. 

(J) Aircrew Debriefing Scenario. An aircrew, returning from a 
Surface Search and Surveillance Coordination (SSSC) mission, heads for the 
aircraft carrier’s Intelligence Center (CVIC) to debrief. They report to the 
debriefing officer that they saw a large, unfamiliar naval combatant, but due to 
poor visibility and nearby restricted airspace they could not get closer to take a 
photograph for later positive identification. 

The debriefer accesses GEGTREC’s unit identification function 
to assist in the aircrew's recall. The menu-driven Query/Response session goes as 
follows: 

• GEGTREC: What type of unit would you like to identify? (aircraft, aircraft 
earner, surface combatant, submarine, auxiliary, merchant ship, other) 

• Aircrew/Debriefer: Surface combatant. 

• GEGTREC: What size surface combatant? (major, minor, patrol boat) 

• Aircrew/Debriefer: Major. 
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• GEOTREC: Which of these major features are vou certain the unit 
possessed? (missile launchers, guns, stacks, helipad, torpedo tubes, radar, 
AT rfl 

• Aircrew/Debriefer: Missile launchers, helipad. 

• GEOTREC: Let’s start with missile launchers. Where were the launchers 
located on the unit? (forward, amidships, aft, ALL) 

• Aircrew/Debriefer: ALL. 

• GEOTE^C: What type of launchers were the forward launchers? (single¬ 
rail, double-rail, tube/canister, below-deck/vertical launch, UNSURE) 

• Aircrew/Debriefer: Double-rail. 

• GEOTREC: What type of launchers were the amidships launchers? (single- 
rail, double-rail, tube/canister, below-deck/vertical launch, UNSURE) 

• Aircrew/Debriefer: Tube/canister. 

• GEOTREC: What was the configuration of the tubes/canisters? (single, two 
side-by-side, two stacked, three side-by-side, cluster of three, four side-by- 
side, cluster of four, UNSURE) 

• Aircrew/Debriefer: Cluster of four. 

• GEOTREC: What type of launchers were the aft launchers? (single-rail, 
double-rail, tube/canister, below-deck/vertical launch, UNSURE) 

• Aircrew/Debriefer: UNSURE. 

• GEOTREC: Now let’s consider the helipad. Where was it located? 
(amidships, aft) 

• Aircrew/Debriefer: Aft. 

• GEOTREC: Where was the helipad in relation to the unit’s general 
deckline? (raised, flush, lowered, UNSURE) 

• Aircrew/Debriefer: Raised. 

• GEOTREC: Was there an associated helo hangar? (yes, no, UNSURE) 

• Aircrew/Debriefer: UNSURE. 

• GEOTREC: Could the identified unit have been a KRESTA II CG, one of 
which is pictured here? 
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At that point, the GEOTREC system displays a photograph of 
a Soviet KRESTA II class cmiser, as it is the only candidate in the database 
which met the criteria delineated in the Query/Response session, even with the 
"UNSURE" responses. The aircrew then scrutinizes the on-screen photograph, has 
the Debriefer ask GEOTREC to display other shots of the unit to view it from 
different angles and in different lighting, and makes their determination: the unit 
tliey saw was probably a KRESTA II CG. 

To confirm this, the Debriefer uses GEOTREC’s textual 
information features to get an order-of-battle listing of Soviet cruisers, indicating 
where their homebases are. He sees that KRESTA II CGs are indeed based in 
this theater. The analyst then selects background information, to refresh his 
memory on where these cmisers normally operate, finding that they often anchor 
in the protected waters under the same restricted, territorial airspace the aircrew 
had to avoid. From all this evidence, the analyst corroborates the aircrew’s 
evaluation that the unit they sighted was indeed a Soviet KRESTA II CG. 
c. Briefing 

GEOTREC could also be used to prepare and/or conduct briefings 
and presentations. As a supplement to individual, self-paced training, a projector 
could be used to conduct group training similar to that which is the mainstay of 
current threat recognition training. 

Additionally, presentation slides could be generated using the laser 
printer. This would allow the briefer to create slides consisting of his own set of 
annotations and highlights, overlaid on a chart or digitized image. Using these 
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featuxes, briefings could be created covering topics such as exercise scenarios, 
planning for actual operations, contingency target exercises and plans, and the like. 

D. CAN IT BE DONE THAT WAY TODAY? 

The GEOTREC system described above represents an ideal. Such a system, 
with all its features, is not outside the capabilities of today’s technology. But 
there is one major drawback: the software for building such hypermedia 
applications is still in its infancy, and must continue to expand and mature to be 
able to easily and seamlessly handle the various media. Just as important, such 
software must provide authoring tools that are intuitive and well-documented 
enough to be easy to use by non-programmers, while being powerful and flexible 
enough to allow for the broadest possible range of applications to be developed. 

A major objective of this research was to investigate the state of the art of 
such hypermedia application software, using the ideal GEOTREC system described 
in this chapter as a framework and reference point. The specific goals of this 
research were as follows: 

• to review the areas of hypertext and digital optical media; 

• to outline an ideal operational application in which they could be used; 

• to attempt to author such an application using an actual hypermedia 
application development software package; 

• to record the difficulties associated with this authoring attempt; 

• to draw conclusions and base recommendations on this research as to the 
relevance, utility and feasibility of developing such an application for actual 
use in the U.S. Navy. 




















The author’s hypermedia application authoring attempt, with its associated 
problems and findings, is described in the following chapter (Chapter 5), while the 
conclusions and recommendations are made in Chapter 6. 
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V. PROBLEMS/FINDINGS 

A. BACKGROUND 

In order to direct the study and demonstration of hypermedia features, and to 
investigate an example of the present state-of-the-hypermedia-art in terms of 
available software authoring tools, this thesis focused on a specific software 
package for a specific application. Tfte application; the GEOTREC (GEOgraphic 
and Hireat RECognition) Training and Reference Tool (outlined in Chapter IV); 
the software: GECI International’s Hyperdoc, version 1.12. 

Hyperdoc was chosen for several reasons; first, because it is MS-DOS based. 
Apple Computer and other developers of Mac/OS based software have taken the 
lead in developing hypermedia authoring tools and applications. This is largely 
due to the graphical user interface (GUI) inherent to and so familiar in the 
Apple/Mac computer world. Hypermedia packages such as HyperCard (which 
Apple Computer now bundles with almost any purchase of Macintosh hardware), 
SuperCard and Guide have become widely used for hypermedia applications. 

The problem remains, however, that the de facto standard PC (personal 
computer) operating system in tlie U.S. Navy is MS-DOS. Government Computer 
News estimates that, by January 1990, the Department of Defense had purchased 
up to 600,000 IBM-compatible (i.e., MS-DOS compatible) Zenith PCs. ([Ref. 22], 
pp.1,72) In light of tliis, it was considered important for this thesis research to 
utilize an MS-DOS based hypermedia software package. 





















In addition, Hyperdoc was chosen for its advertised capabilities and 
flexibility. Advertisement literature such as a booklet published in 1988 entitled 
simply "Hyperdoc", claims: "HYPERDOC has a CD ROM [sic.] processing 
interface, which allows the use of the best features of this new medium facilitating 
processing and storage of a very large volume of documents in reduced format"; 
and, "Since the document recording format is totally independent of all operating 
systems and all display peripherals, HYPERDOC documents can be run on any 
computer, from mainframe to PC. this [sic.] degree of adaptability guarantees its 
long life despite equipment advancement, a quality essential for the maintenance 
of an expensive documentary archive base on a computer system which is 
constantly changing." These highly desirable characteristics of hypermedia 
software will no doubt be integral to future versions of Hyperdoc as the product 
matures. Unfortunately, the only version of the software available for tliis 
research. Hyperdoc 1.12, did not incorporate either one. 

B. PREPARATION 

In order to begin prototyping the GEOTREC application using Hyperdoc, 
several preparations had to be made, the first being computer hardware. The 
Naval Ocean Systems Center (NOSC) in San Diego, California, greatly assisted 
this research effort by loaning a FULCRUM system, consisting of a Compaq 
Deskpro 386 AT (with a 60 Megabyte internal hard drive, mouse, and VGA 
graphics), a Pioneer LD-V6000A Laserdisc player, and a 12-inch Sony color 
monitor, in addition to the FULCRUM software. This hardware was placed in the 
Naval Postgraduate School’s Optical Laboratory', in order to be able to utilize other 
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hardware available in the Lab as needed, such as CD-ROM drives, an optical 
scarmer, and a laser printer. 

The second preparation was to obtain or produce digitized iinages around 
which the prototype could be built. Ideally, these would be high resolution 
images Of aircraft, ships, submarines, weapons systems, naval installations, 
airfields and the like (whether digitized jdiotographs, line drawings or diagrams, 
maps or charts, or even "artist conception" drawings), stored on optical media 
such as CD-ROM or laserdisc, NOSC’s FULCRUM system came with one 
laserdisc of maps ranging from a world map to detailed charts of the Korean 
peninsula, ideal for demonstrating the capabilities of this prototype. 

Finding a suitable CD-ROM, however, was imsuccessful. The only example 
of a CD-ROM appropriate to this research was seen advertised in the October 
1989 issue tf CD-ROM EndUser magazine (p,79). It is a CD-ROM with the title, 
"Dick’s Some Of The Earth’s Planes" (a tongue-in-cheek name which plays on the 
title of the authoritative Jane’s All The World’s Aircraft encyclopedic series). The 
reader is told that the disk "...contains hundreds of black-and-white and color 
aircraft images", in addition to silhouette images (in .PCX format), and 
information on each plane such as "...air speed, length, wing span, crew, service, 
range and mission". Again, such a disk would be ideal for the aircraft portion of 
the GEOTREC prototype’s database. Unfortunately, the version of Hyperdoc used 
for authoring this prototype was not capable of controlling either a CD-ROM 
player, nor FULCRUM’S laserdisc player, so the search for available optical disks 
became inconsequential. 
























For this reason, efforts were directed at scanning images onto hard disk. 
These images were obtained from such sources as issues of Jane’s Defence Weekly 
and U.S. Naval Institute Proceedings magazines, as well as Norman Polmar’s 
comprehensive Guide To The Soviet Navv . [Ref. 23] The process was difficult 
and time-consuming for several reasons, the most significant of which was 
Hyperdoc 1.12 only accepts images that are stored in the .PCX standard file 
format. Because of the limited, nature of this file format, image selection had to 
be very restricted; for instance: 

• only photographs with sharp object/background contrast could be utilized (for 
example, photos of submarines were particularly difficult to use, as they 
almost always consist of a very dark object, the submarine, against a dark 
background, the surrounding ocean); 

• only small photos (i.e., something less than 4x5 inches) could be utilized, 
as anything larger would translate into too much digital infonnation to be 
stored in the .PCX format; larger photos could be scanned in and then 
reduced in size to meet the .PCX limitations, but at a great loss of detail; 

• the images obtained were at very low resolutions (i.e., normally 75 dpi [dots 
per inch], with some at 120 dpi, depending on the size of the original image 
and the seamier used), again, losing all but the most obvious details. 

Two scanners were used to capture the images: the Xerox 7650 Pro Imager, 
and the Discover 7320. Although the large-screen Xerox 7650 System had by far 
the more capable scanner (including exceptional image viewing, editing, and 
manipulating capabilities), the system often crashed during conversion attempts, as 
its RES (Xerox’s proprietary image file format) to PCX conversion utility was not 
formally supported by the resident software release. Each system crash would 
require a twelve minute reboot process. In addition, the Xerox was capable of 
handling only black-and-white images. The Discover 7320 was more robust and 
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easier to use, but provided no way to preview the image before scanning, or to 
view or manipulate the image after scanning, so all adjustments had to wait until 
the image was imported into ZSoft Corporation’s PCPaintbrush (the use of which 
is ftuther explained in the following paragraphs). 

Adding to these difficulties. Hyperdoc’s conversion tool can only handle a 
small subset of the several .PCX variants within the standard. That is, only .PCX 
files that are output from a paintbrush program, such as Zsoft Publisher’s 
Paintbrush or ZSoft PCPaintbrush can be correctly converted by Hyperdoc. 
Consequently, a copy of ZSoft PCPaintbrush had to be obtained, loaded, and 
learned. All .PCX files created by the scanning process had to be loaded into 
PCPaintbrush (even if no editing changes had to be made), and then saved back to 
disk. Only then could the Hyperdoc conversion utility be used to successfully 
convert the .PCX file to Hyperdoc’s proprietary file format (.YGO). If the scaimed 
.PCX files were directly converted by Hyperdoc without first calling them into 
PCPaintbrush, the final product came out distorted, with a severely "squashed" 
appearance (i.e., full width, but only one-third height). 

C. EVALUATION OF HYPERDOC 

Once the images had been scanned in and converted to Hyperdoc’s .YGO 
format, the authoring began. The authoring, in and of itself, proved to be quite a 
challenge. 

It should be noted up front that Hyperdoc does have some good points. For 
instance, the Hyperdoc, USA, office in San Jose, California, is staffed with 
friendly, accommodating personnel, who were always available via telephone for 
technical support and advice. Also, Hyperdoc’s file extension scheme was 



















intuitive, consistent and helpful, distinguishing each of the many types of files 
used by Hyperdoc, and yet keeping them appropriately related (with one minor 
exception, noted later in this chapter). In addition, the windowing features were 
substantial, allowing for several helpful features, such as the automatically added 
"move menu" option appended to all menus created with Hyperdoc’s "MENU" 
command. Most importantly. Hyperdoc is moving in the right direction for 
supporting hypermedia application development, with a wide variety of good ideas 
and advertised features which, if brought to fmition in later Hyperdoc versions, 
will comprise an excellent hypermedia package. 

On the negative side for version 1.12, however, the list is long. In general, 
the difficulties encountered by the author were primarily in the areas of: 

• poor documentation (both on-screen and paper); 

• non-intuitive, inconsistent user interface; 

• many capabilities were more limited than advertised; 

• non-robust, incomplete, non-seamless, unpolished package; 

The paragraphs below provide a sampling of specific Hyperdoc "rough 
spots". 

1. Poor Documentation 

The documentation that accompanied the Hyperdoc software was sparse, 
skeletal, and incomplete. For example, the written documentation included no 
index for quick-reference, and no printed sample action files (Hyperdoc’s term for 
program files written in Hyperdoc’s command programming language), although 
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simplistic action files from a sample application were included on diskette. Other 
specific examples of problems in the documentation are as follows: 


• The documentation contained a plethora of misspellings, missing words, 
incorrect grammar, run-on sentences, and other such elementary errors; here 
is a sampling: 

-> p.43 of Hyperdoc Command Reference, under "MENU" entry, usage is 
spelled "USUAGE", and the very next sentence reads, "...Returns 0 if user 
presses ape key." 

-> pp.27,28 of Hyperdoc Command Reference, the entries are out of 
alphabetical order ("DISDOC", "DISTEXT" and "DISTEXTSTOP" are listed 
after "DOS" and "DOSEXECUTE") 

-> p.25 of Hyperdoc User’s Guide, under PAN & HOME entry, reads: 

"The Home function is use to re-align the image with the upper left comer 
of the document with the upper left comer of the screen." 

-> p.29 of Hyperdoc User’s Guide, under PASTE entry, reads: 

"The Paste fiinction is used to merge a different document into the one 
currently being editing on." 

-> p.31 of Hyperdoc User’s Guide, second paragraph on the page, reads: 

"In order to move a document created at higher scales (smaller images) into 
a lower one (larger images) the Convert scale function is used. The effect 
of this function is the same as if the document were created at the lower 
scale factor to." 

• In the Hyperdoc User’s Guide (p.53), the instmctions on how to use the 
Library editor to create new commands is severely lacking. For example, in 
describing the menu choice "EDIT", the instmctions read only, "This option 
enables the developer to: 1. modify an existing function; 2. create a new 
function" -- and nothing further. 

• In the Hyperdoc Command Reference, the "CLOSEWIN" command is 
particularly difficult to find, as it is neither included in the table-of-contents 
listing, nor indented and bolded for emphasis as are all the other commands; 
furthermore: 

-> the reference lists this command as "CLOSEWINDOW", 
when in reality it is "CLOSEWIN"; 

-> it erroneously states that this command can only be 

used after tlie "OPENWND" command is issued (in fact, "CLOSEWIN" must 

be used in conjunction with several other commands, such as 

"DISTEXTWIN"); 

-> its reference to the "OPENWND" command just described 
is incorrect, as the actual command is "OPENWIN". 
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• The documentation does not provide a listing of available fonts by file name 
(e.g., "System72.fnt"), but offers no indication of what these available fonts 
would look like (pitch, type, etc.) when invoked by an action file. 

• In several places (e.g., in the Graphics editor), some of the menu selection 
names given in the documentation differ from those names actually given 
on-screen; case in point, the SPECIAL TOOL named "HDSCALE" is listed 
in the Hyperdoc User’s Guide as such, but appears on the menu as 
"HDECHEL" (which is no doubt the abbreviated French equivalent for 
"HDSCALE", as Hyperdoc was originally written in French); also, one of 
the tools is Usted as "CONFIG.EXE" in the User’s Manual, but appears as 
"HDCONFIG" on the menu. 

• Very little explanation or instruction is provided in the documentation for 
using Hyperdoc’s SPECIAL TOOLS, either in the paper documentation 
(where there is a total of one half page given to the entire topic) or on-line 
(where tliere is no assistance whatsoever). 


2. Non>intuitive, Inconsistent User Interface 

The user interface provided by Hyperdoc 1.12 was largely non-intuitive 
and inconsistent, making for a very steep and long user learning curve. Menu 
options were often confusing and nondescript. In some cases, the same key was 
assigned different functions at different times for no apparent reason. While some 
of the problems were little more than annoyances, others made it difficult to learn 
and accomplish what was intended in a reasonable amount of time. Some of the 
specific user interface difficulties were: 


• In the Graphics editor, under the FILL POLYGON option, after designating 
coordinates for the polygon’s comers, the user must press ESC, instead of 
something intuitive like ENTER, to get the editor to close and fill the 
polygon. 

• Also, in the Graphics editor, a RIGHT TRIM option is provided to allow the 
user to slice off part of the right edge of the graphic if desired (it is 
perplexing why only RIGHT TRIM is available, and not also LEFT, TOP 
and BOTTOM TRIM); the problem is, however, that the original graphic is 
never cleared from the screen, and the new version of the graphic, with its 
trimmed right edge, is redrawn directly atop the old graphic; consequently, 
the user is prevented from viewing the new graphic (as is appears with its 
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right edge trimmed off) prior to confirming whether he wants to save it to 
disk and replace the old graphic. 

• Upon exiting from the graphics editor, the image that was being edited is 
automatically redrawn at one-fourth scale in the upper left comer of the 
screen imd on top of the original image; not only is Uiere is no apparent 
reason for this, but in the case of complex images, it can be extiemely time 
consuming, even on a 16Mhz 386 machine; ftUlhermore, foUowm^^ 
redraw, a box appears atop the redrawn image with the enigmatic message, 
"Display drawing at scale required for level 1" ^ewline> "Hit FI to modify 
the ^splay"; that’s it ~ no further instructions, explanation, or indication of 
what module or fimction you are in, or what your other options are; in order 
to exit this and not modify the display, the ESC key must be used, although 
the user is not told this in any documentation other than the tutorial. 

• In the Deseriptives editor, when an object (similar to a function or procedure 
in stmctured programming languages) from an action file is called up for 
editing, none of Ae instmctions that are normally shown in the Object editor 
are displayed -- the user has to rely on recall as to what keys are used to 
edit, save, exit, etc.; in addition, the ESC key, which is normally used in the 
Object editor to produce an END_OBJECT designation, does not produce the 
same result (instead, although no indication is given on-screen, an 
END_OBJECT designation is added automatically upon exiting from the 
Deseriptives editor, unlike the Object editor). 

• Throughout Hyperdoc, the indication for the user to wait while the system is 
processing is inconsistent: sometimes it appears as a little hourglass in the 
center of the screen (good), sometimes as successive dots emanating from 
the left, center edge of the screen (hard to see, and meaning unclear), and, 
more often than not, nothing appears at all (undesirable). 

• Concerning Hyperdoc menus, the user is forced to highlight the desired 
selection (using the mouse or up/down arrow keys) and then press ENTER 
(or the left mouse button); the user cannot simply press the number or the 
first (or other designated) letter corresponding to die desired menu choice to 
make a selection; and while it is convenient to be able to use either 
keyboard or mouse, this can be very tedious for an advanced user who 
would rather enter series of letters in order to speed through a series of 
known menus (as provided in LOTUS 1-2-3, inter alia), instead of having to 
go through every single menu one by one. 

• Hyperdoc 1.12 exhibits a bizarre, non-intuitive, inconsistent, and yet 
ubiquitous, use of the ESC (escape) key: 

-> when attempting to exit from an editor or other feature, the message 
typically appears: "Hit ESC to finish"; one would think this was fiinctioning 
as an exit confirmation ("Do you really want to exit this feature?"); however, 
the user is not allowed at that point to undo his selection (i.e., to say, "No, 
that’s NOT what I wanted to do" by pressing ESC or some other designated 
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key); thus, hitting ESC to finish is apparently an unnecessary step which 
quickly becomes a nuisance; 

-> in fact, at some points where "Hit ESC to finish" appears, pressing 
any other key besides ESC (such as ENTER) has detrimental consequences; 
for instance, in the Object editor, after editing and exiting from an action 
file, if the user presses ENTER at the "Hit ESC to finish" prompt, he is 
again asked for the name of a file to be edited, apparently allowing the 
continued use of the Object editor without having to reselect if from the 
menu; this would be a convenient feature if it worked; however, the outcome 
of any subsequent action file editing is unpredictable, can often engender a 
message that the file being edited (even if small) is too large and needs to 
be divided up, and may sometimes result in the loss of data; 

-> in the drawing menu, under the CHANGE LEVEL option, the user is 
directed to move the crosshairs to designate the desired center for the new 
level of the drawing, after which he must press ESC to execute that 
designation (although this is NOT mentioned anywhere on the screen or in 
the documentation, except in the tutorial); 

-> in the Object editor, as mentioned previously, the ESC key is used 
to produce the "END_OBJECT" character, instead of something more 
intuitive and self-explanatory such as the END key (or the CTRL-END key 
combination, since END is used to move the cursor to the end of a line). 

• In general, on-screen instructions (as to the function of various keys, how to 
get help, how to get to the previous screen, how to exit, etc.), as well as 
error messages, are cryptic, misspelled, improperly spaced, and woefully 
inadequate (e.g., in the Graphics editor, under Ae CONVERT SCALE 
option, the message to the user reads: "To be completely displayed on the 
screenthe drawing must be in the scale 4" <newline> "initial scale: •+•", where 
the "-f" is followed by 1, 2, 3 or 4, and the words "screenthe" are run 
together as written here). 

• The SCALE FACTOR, used in the Graphics editor and other places, is a 
user-changeable variable which has a possible range of 1 - 4 (for 1/1, 1/2, 
1/3, 1/4 scale); the use of words such as "full-size", "half-size", "third-size", 
and "quarter-size" to represent these quantities would be much more clear; 
all the more so because the SCALE FACTOR is used hand-in-hand with 
another such variable, DISPLAY LEVEL, which also ranges from 1-4, 
allowing the two to be easily confused (perhaps DISPLAY LEVELS could 
be expressed in letters such as, "A, B, C" etc.); furthermore, a SCALE 
FACTOR of 3 cannot be used other than to temporarily view the image at 
that scale (images can only be saved at SCALE FACTORS 1,2 and 4). 

• Hyperdoc has given non-mnemonic names to its SPECIAL TOOLS utilities: 
"HDVC" for the conversion interface utility which can only be used with 
image files scanned in using a Microtek 300A scanner; "HDHYPPB" for the 


51 














Hypendoc-to/from-PCX conversion tool; 'HDEDCMM" for the command 
editor; and so on. 

• The Hyperdoc files containing the application audior’s programming code are 
sometimes referred to as "action files", land sometimes as "object files" or 
"objects" (they all end with a ".YOB" extension, "OB" presumably for 
"OBject"); however. Hyperdoc in reality makes a distinction between objects, 
which ate like functions or procedures in structured programming languages, 
and the files which contain those objects (each fiJ^e can be comprised of any 
number of objects); as such, the action files should be consistently referred 
to as such (with perhaps a ".YAF" extension), and edited with an "Action 
File" editor (vs. an Object editor as it is presendy called). 

• Many of the Object editor’s key comb inations are confusing and hard 

to remember; for instance, the CTRL-N combination is used for MOVE 
BLOCK, when the more intuitive CTRL-M (M for Move) is not being used 
elsewhere; CTRL-G is required for REPLACE BLOCK; CT^-R for COPY 
BLOCK; etc.; in addition, while the FI key does bring up a help window 
listing all these key combinations and their usage, this window cannot be left 
open for reference purposes during editing (every time the user needs to 
refer to it, he must stop editing, c^ Up the window, look at and remember 
the key combination, and then exit the window, return to editing, and use the 
proper key combo). 

• In many instances. Hyperdoc will not allow die user to undo undesired 

entries; for instance, when attempting to editing a graphic document, the user 
is asked to enter first the X coordinate and then die y coordinate of origin 
(the screen coordinates at vdiich^ fe^ comer of the image will 

tegin), and is then asked for the SCALE FACTOR; after fee user enters a 
number for the x or y coordinate and presses ENTER, he cannot go back 
and change the entries, or get out of that function; pressing the ESC key at 
this point (the intuitive way to say "No, that’s NOT what I want to do -- 
take me back") is the same as pressing ENTER; thus, die User is forced to 
either go through with that operation (which could involve another lengthy 
graphi(^ image drawing) or reboot the entire system (more often than not 
the more expeditious of &e two options). 

• The Object editor and the Text editor shared many of the same problems in 
terms of user interface; 

-> with each and every backspace movement or delete keystroke, the 
entire screen is redrawn, which is not only slow and annoying, but also 
prevents tracking the cursor to see how much is being deleted until all the 
blinking stops; 

-> no clear indication is given as to whether the editor is in the insert 
or typeover mode, such as changing the cursor’s size or color; all that is 
provided is a small "Rempl." (assumed to be abbreviation of French word 
for replace) or "Insert" in die upper left comer of screen; 

-> the user must enter hard returns at the end of every line; if inserting 
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a new line between two adjacent, existing lines, the user must hit return, 
then type the text of the new line, then hit return, which puts in an 
unwanted blank line, and then delete the blank line just created; if this is not 
done, the text of the third line will begin immediately after the last character 
of the second line when the object file is subsequently retrieved); this is 
especially agonizing when a large portion of text (multiple lines) is blocked 
and then moved or copied — once the block move or copy is complete, a 
hard return must be inserted after every line, and the bla:^ line which is 
produced by inserting each hard return must then be deleted one at a time; 

-> when text is blocked down to the end of an action file, and that block 
is deleted, any attempts to scroll back up in the file (i.e., repeatedly moving 
the cursor upward) results in the cursor disappearing off the top of the 
screen, and the editors locking up, requiring a system reboot; 

-> the editors also lock up when the user attempts to place a copied block 
of text immediately above the original block, requiring a system reboot. 


3. Limited Capabilities 

Hyperdoc version 1.12 includes no CD-ROM interface capability, and 
can only handle .PCX graphics format (with the exception of only one, little- 
known "Microtek 300A" format scanned files). In addition, each Hyperdoc 
graphical image file can reportedly provide resolutions of up to 4000 x 6000 
pixels - however with the scanner and .PCX limitations, this capability is 
essentially unusable. 

In addition, while some versions of Hyperdoc can interface with a 
videodisc player — albeit, only one specific model of one specific brand (i.e., 
Pioneer LD-V3500) — no such capability was included with the software used for 
this research. Furthermore, action files (i.e., ".YOB" files) can be created in other 
word processors and then imported as ASCII files into Hyperdoc, but once 
imported they can not be edited using other text editors (QEDIT, 
WORDPERFECT 5.0, and EDLIN all failed); Hyperdoc’s Object editor apparently 


53 

























changes the commands in the action files to numbers, and then inserts non- 
piintable characters as in a compiled, executable file). 

Finally, gateway commands to other application programs (e.g., 
''WAITEXECUTE'') do not work with any but the smallest executable programs 
(e.g., .CX)M or .BAT files), due to memory limitations. That is, enough of 
Hyperdoc stays resident in memory (vs. written to disk) that attempts to use other 
applications such as INGRES 5.0, PARADOX 3.0, and WORDPERFECT 5.0 were 
all futile (a tenuous workaround was u^d in GEOTREC and will be described 
later in this chapter). 

4. Non-robust, Unpolished Presentation 

In addition to being accompanied by poor documentation, providing a 
laborious user interface, and a reduced capability to interface with other products. 
Hyperdoc version 1.12 failed to present itself as a robust, complete, mature 
software package. It had difficulty handling user mistakes, unexpected key 
combinations, out-of-range inputs, and other Such anomalies that robust software 
should be able to manage, even if only by displaying explanatory error messages 
and returning the user to the state of the program prior to the anomaly’s 
occiurence. Moreover, Hyperdoc did not provide a seamless, polished look and 
feel the author expected of a mature software package in the $1000 price range. 

The following are specific instances that support these judgments: 

• Many of the on-screen instructions and error messages are still in French; for 
instance: when saving action file changes made in the Object editor, the 

user is asked to enter "Nom de la copie: when the number of windows 
opened in the application at any given time exceeded memory constraints, 
the error message appears, "Trop des fenetresin the Graphics editor, 
when designating the center for the new version of the graphic, the user is 
prompted with "Nouveau centre:"; and even the executable file which 
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produces the main menu for Hyperdoc Tools is named HDOUTILS.EXE (as 
opposed to HDTOOLS.EXE). 

• When the main Hyperdoc Tools menu is displayed by HDOUTILS.EXE, the 
menu is noticeably off-center on the screen, just under its title-caption 
"Hyperdoc Tools" which is centered, thus exacerbating the faulty positioning 
of the menu. 

• When in the Graphics editor, if the user accidentally selects an incorrect 
menu choice, there is no way to abort the on-going function (e.g., by 
pressing the ESC key); in the case of a large, complex graphic, this means 
waiting as long as twenty seconds or more for the graphic to be drawn, then 
exiting from that accidentally chosen function, returning to the menu, 
selecting the correct function, and then waiting another twenty seconds for 
the graphic to be drawn under the correct function. 

• Also in the Graphics editor, the FILL POLYGON option does not work 
properly; the user is first asked to designate the first comer coordinate, then 
prompted to specify the color of the fill, instead of being asked for more 
comer coordinate designations; after selecting the color, the user is asked for 
another comer coordinate, followed immediately by a request to once again 
specify the color of the fill; finally, after designating all desired comers, the 
user is directed to press the ESC key (as opposed to the ENTER key, a 
much more intuitive option at that point) to fill the polygon — however, the 
ESC key returns the user to the Graphics editor menu, without the polygon 
being drawn or filled. 

• Again in the Graphics editor, when attempting to exit the EDIT option, the 
system locks up entirely, requiring a cold system reboot (i.e., no keyboard 
inputs are accepted whatsoever, not even CTRL-ALT-DEL) 

• And finally in the Graphics editor, under the SAVE BLOCK option, the 
system locks up when the user attempts to overwrite the graphics file 
currently open for editing; Hyperdoc should either tell the user it is an 
invalid operation and that he should save the block to a different file name, 
or else allow him to do the overwrite. 

• When finished with image conversion (PCX-to-Hyperdoc), using the 
"HDHYPPB" special tool invoked from the Hyperdoc Tools menu 
(HDOUTILS.EXE), the user is not returned to that menu, but rather is taken 
out of HDOUTILS completely and returned to the DOS prompt with no 
explanation message en route. 

• When Hyperdoc is transitioning between modules, the apparently 
meaningless, system-level message, "HYPERDOC : final control = 0/0" is 
almost always displayed on an otherwise blank screen; this, in addition to 
the ubiquitous "Hit ESC to confirm" message described previously, make for 
very rough, non-seamless transitions between modules and functions. 
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• At several other transition points (e.g., within the IX)Cl^^ on 

the main Hyperdoc Tools menu, ^er entering "G" for document type, and 
then the document name), the screen totally blanks out, followed by the re¬ 
display of the exact same screen, with just a sli^tly different data-entry 
window overlaid; retention of the same background with changes to the data- 
entiy window would be preferable. 

• The "browser" feature only works after the PRQCESSDOC command has 
been invoked (i.e., only when image/text jfile is displayed oii-sereen awmting 
user selection with mouse); in itself, the browser is a very useful feature, but 
it would be much more so if it tracked action file code-generated images or 
text (e.g., DISDOC, MENU, DISTEXT, etc.); also, when clicking on a 
browser icon (representing a "PROCESSDOC" graphic or text), or after 
exiting the browser, the screen is not cleared, so diat if the document being 
processed is not full-screen, the browser can stiU be seen in the background, 
providing unnecessary screen clutter. 

• Some inconsistencies exist in the object programming commands used to 
create action files: 

-> most screen-output commands, such as "WRITE", allow the author to 
select both the background and the text colors (a good feature), whereas 
some, for instance the "DISTEXT" command, accept only one color 
parameter (with no corresponding list provided in the documentation as to 
what two colors result ftom each single parameter); 

-> the "DISTEXTSTOP" command does not accept a cursor parameter, as 
indicated in the Command Reference Guide; rather, it displays the number 
given for that parameter on the screen as if it were part of the text being 
displayed; 

-> no logical AND or OR capability is provided (e.g., the hypermedia author 
cannot pro^am the equivalent of: "IF x > 3, OR x = 2, THEN..."); a 
related limitation is found in the "CHOICE" command (similar to a 
SWITCH statement in the C language, or a CASE statement in Pascal) in 
which it is impossible to specify one command for multiple, successive cases 
(e.g.; cannot say "CASE=1, 2 or 3: <commandl>"; instead it must be spelled 
out, "CASE=1; <commandl>; CASE=2: <commandl>; CASE=3: 
<commandl>;", creating redundancy, difficulties in program maintenance, 
etc.) 


D. THE PROTOTYPE GEOTREC APPLICATION 

Die prototype GEOTREC application was designed with a twofold purpose: 
first, to explore Hyperdoc’s hypermedia capabilities in an actual application; and, 
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second, to produce a prototype which included some of the functionalities essential 
to an ideal GEOTREC of the kind outlined in Chapter FV. 

The design was based on several key assumptions: 


1. a login procedure would be required to limit access to authorized personnel 
only; 

2.. two access levels would be required, a read-only level for the ordinary 
authorized user, and a read/write level for a System Administrator who would 
be responsible for updating,, modifying and maintaining the application (e.g., 
adding in newly scanned images, or updating the list of valid users and their 
passwords, and the like); 

3. the user should be able to access other applications, such as databases and 
the FULCRUM application refeixed to earlier in this chapter, via the 
GEOTREC/Hyperdoc shell; 

4. the majority of information the user would need in order to access and use 
all features of the system would be provided on-screen; and, 

5. the code would be general, consistent and documented enough to permit easy 
modification and/or adaptation for future uses beyond this thesis. 


The appendices accompanying this thesis provide the clearest possible picture 
of the GEOTREC prototype developed for this thesis research. Appendix A is a 
collection of GEOTREC screens and accompanying explanatory text, organized 
into a tutorial-like run-through of GEOTREC’s salient features. Appendix B is a 
copy of the GEOTREC action files (.YOB), containing the programming code 
written in Hyperdoc’s command language, as well as the few DOS-level batch files 
(.BAT) written in plain ASCII format, which were used in the prototype. 

The batch files are included as an integral part of the gateway workaround, 
needed, as previously mentioned, because Hyperdoc’s gateway commands do not 
function within the MS-DOS 640K memory constraint as required by GEOTREC. 
To reiterate, a gateway should ideally allow the user to exit the primary 
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application, enter and normally use a secondary application, and then return to the 
primary application just where he left off. 

To get around gateway difficulties to other applications in Hyperdoc, a very 
rough, but functionally equivalent route has been tal^n. Any action file viiich 
would normally call a secondary application directly (using Hypeidoc’s 
WAITEXECUTE command), instead calls a DOS-level batch file (by using the 
DOSEXECUTE command). Hiat batch file then calls the secondary application, 
remains resident in memory until the application is finished running, and then 
continues by calling the GEOTREC.BAT batch file, thereby restarting GEOTREC 
from the beginning (including logging in, et al). While this is clearly 
unacceptable for a full, completed application, it was considered an appropriate 
alternative for this working prototype. 

The general GEOTREC design consists of three major functional areas: 

1. the user-driven viewing and investigation of digitized unit, weapon, and 
sensor images, and their related explanatory text using hypermedia links; 

2. the system-driven Recognition Quizzer, which randomly displays images of 
units, weapons, sensors, etc., and asks the user to identify the item from a 
provided list of choices; and, 

3. the aforementioned gateways to other applications. 

All users initiate interaction with GEOTREC by logging in, using both an 
alphanumeric user identification code, and then an alphabetic password. After 
login, the viewing and investigation of images and related information is reached 
through a series of menus. This menu hierarchy is designed to help the user 
channel his search by logically breaking the available database of images into 
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functionally related areas (e.g., fighter aircraft, major surface combatants, naval 
guns, airborne radar, etc.). 

Once a specific image is selected for display, say, a picture of a certain class 
of surface combatant. Hyperdoc’s hypermedia links allow the user to click on any 
major feature of the unit to receive further information. Generally, that 
information initially comes in the form of a short label (e.g., "This is an SA-N-3 
missile launcher."). Concurrently, an instmction box appears, asking the user to 
either press "M" for More information about that particular feature, or to press any 
other key to continue clicking on other features. 

If the user presses "M" for More information, either a text box or a more 
detailed image of the selected feature appears. No matter which one of these new 
displays is overlaid on the initial image, it also contains hyperlinks, so that 
clicking on any major object phrase or feature will call more information. Again, 
this new information display, either image or text, will in turn have hyperlinks for 
further inquiry. 

And, as described in Chapter IV and shown in Appendix A, the "browser" 
can be invoked at any time during this "click-and-search" session. This allows the 
user to view a diagrammatic "roadmap" of the information path taken to that 
point. It also allows him to click on any part of that roadmap, instantly taking 
him to that node in the search diagram, and displaying the information (text or 
image) represented by that node. 

The Recognition Quizzer puts a different twist on the user’s information¬ 
gathering and learning experience; instead of the user specifying what he wants to 
see and then having it displayed, the system displays what it randomly "wants" the 


59 














user to see, and then asks the user to indicate what it is he is seeing. The user is 
given three chances to correctly identify the displayed item, after which, if 
unsuccessful, he is given the correct answer. Whether he has identified the item 
accurately or erroneously, the user is permitted to further investigate the image 
using its hypermedia links in the exact same manner as previously described. 
When he is finished with such investigative forays, the Quizzer returns to its 
random generation of images for continued testing and learning. 

Finally, GEOTREC’s gateways allow for the incorporation of various other 
applications into what ideally appears to the user as one cohesive, didactic whole. 
In this prototype, gateways are provided to the following applications; 


• FULCRUM, a geographic information and database system developed at 
NOSC San Diego. Among a wide range of other functions, FULCRUM’S 
capabilities include tlie retrieval and display of digitized maps and charts 
which are stored on laserdiscs. FULCRUM allows the user to overlay 
annotations and data sets (e.g., unit positions, tracks, range circles/ellipses, 
and much more) on the geographic images, and would be invaluable as a 
geographic training and reference aid in the context of the GEOTREC 
application. 

• The THREAT DATABASE, an Ingres 5.0 application which provides for the 
retrieval of requested data (text only), eiUier menu-driven or using SQL 
(Standard Query Language) queries; 

• PARADOX 3.0, an easy-to-use, yet extremely capable relational DBMS 
(database management system) that could be used for locally generated 
database requirements; 

• HYPERDOC TOOLS, allowing the System Administrator access to the full 
range of Hyperdoc’s tools for application modification and maintenance. 


These applications provide capabilities far beyond what could be produced 
with Hyperdoc’s authoring tools; indeed, therein lies the beauty and importance of 
"other-application gateways" in any hypermedia software package. Moreover, 
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these in no way comprise the definitive Set of siich relevant applications, but 
rather only serve to illustrate the types of applications which can be linked 
through the GEOTREC application. 

Due to time constraints, not every option of every menu in this prototype is 
presently available. In addition, due to previously described scanner difficulties as 
well as hard disk constraints, only a limited number of images have actually been 
incorporated into the prototype. For these reasons, an action file named 
"GENERIC.YOB" (see Appendix B) was created, and is called when appropriate 
to indicate to the user the general format in which a response to his request would 
be displayed once that option or image became available. Obviously, in a 
complete version of the GEOTREC application this file would be superfluous. 
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VI. CONCLUSIONS/RECOMMENDATIONS 
A. CONCLUSIONS 

The surveys of hypermedia and DOM (digital optical media) technologies 
conducted as background for this thesis (Chapters n and HI, respectively), as well 
as the prototype implementation of the GEOTREC application which formed the 
focal point of this research (Chapters IV and V, and Appendices A and B), have 
yielded conclusions and recommendations, the most significant of which are 
addressed in this final chapter. 

Of the major conclusions to be drawn from this study, perhaps the most 
evident is that Hyperdoc version 1.12 presented limitations which negatively 
impacted the authoring of die GEOTREC prototype. However, despite version 
1.12’s numerous drawbacks, Hyperdoc’s basic design is sound, with some presently 
implemented capabilities which are solid, and an advertised future direction which 
appears well-chosen. Indeed, more mature versions of Hyperdoc, in which 
shortcomings such as those outlined in Chapter V have been competently 
addressed and rectified, could well become a front-runner in the field of 
hypermedia software and application generation. 

Additionally, it can be concluded that the MS-DOS operating system 
environment may somewhat constrain hypeimedia applications like GEOTREC. 
These applications, which involve handling numerous graphics and gateways to 
other applications, often require large amounts of primary memory, beyond the 
640K standard to MS-DOS. And while various expanded memory options are 
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now readily available for MS-DOS, they can dramatically increase system 
complexity and expense. More importantly, it can be assumed that very few of 
the MS-DOS based PCs currently in Fleet use have extended memory capabihties. 
Furthermore, aside from some of the very latest releases, few of tlie software 
packages which would be useful in such an application (such as those used in this 
thesis research and prototype, including Ingres 5.0, Paradox 3.0, WordPerfect 5.0, 
and Hyperdoc version 1.12) can- utilize expanded MS-DOS memory. 

This thesis has underscored advantages of using both hypermedia and DOM 
for an application like GEOTREC. The process of learning is done much more 
efficiently and effectively when information is presented at the proper pace in a 
variety of media. Hypermedia not only provides multimedia stimuli, but also 
allows user-paced and -directed instruction which accommodates each user’s own 
leammg abilities, strengths and weaknesses. In addition to superb educational 
characteristics, hypeimedia provides an ideal avenue for quickly refeiencing 
desired information by allowing speedy location and retrieval in multiple formats, 
with related support data just a mouse-click away. 

High-resolution graphical images are enormously expensive in teims of 
digital storage, particularly if they are in color or a fine-grain grey-scale. 
Moreover, the images utilized in this appUcation are static in nature, changing 
only when corresponding updates to the order-of-battles occur in applicable 
mihtaty services. DOM not only provides permanent storage of this infoimation 
to a secure, convenient, cost-efficient format, but also permits its rapid mtrieval. 
without using up valuable hard disk space needed by application programs. 
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A final conclusion from this investigation is the utility and sagacity of 
authoring, that is, providing tools so the end user can develop prototype 
applications to meet his ovra needs. Prototyping has become one of the most 
valuable system design and development tools, particularly for relatively small, 
non-complex applications such as GEOTREC. Allowing the user to actually 
perform prototyping through authoring not only ensures that user requirements are 
being met, but that user acceptance will be forthcoming, leading to overall system 
implementation success. 

B. RECOMMENDATIONS 

The primary recommendation of this thesis is that the problem of geographic 
and threat recognition training and readiness be addressed with hypermedia and 
DOM solutions. Whether in the format of the GEOTREC prototype developed for 
this research effort, or in a different genre, it is clear that a meshing of 
hypermedia and DOM technologies would provide the best solution to a pressing 
operational need. 

In order to make this feasible, the use of high-quality hypermedia authoring 
software is recommended. Such software must provide clear, concise on-line 
documentation (preferably implemented with hypertext features), with in-depth 
coverage provided by accompanying paper documentation. The documentation 
should include glossaries, indexes, quick-reference sections, a broad variety of 
sample code files and programs, toll-ffee/24-hour assistance phone numbers, and 
the like. 
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In addition, such software must provide smooth access to, or better yet have 
mtegrated within it, device drivers for some or all of the following: image 
scanners, CD-ROM drives, laserdisc drives, and WORM diives for locaUy- 
obtained or locally-produced images. This software must also be capable of easily 
handling all major PC graphical file formats, including TIFF (Tag Image File 
Format), and EPS (Encapsulated PostScript), in addition to PCX. 

Furthermore, it is suggested that such software be able to integrate one or 
more DBMSs (database management systems), beyond simply providing a DBMS 
gateway. In such a case, information could be approached by the user from the 
angle: "Give me a list of all ships with SS-N-22 launchers, ADMO-630 guns, 
AND amidships helipads", and when that list appears, the user could click on onJ 
of the names in the list to view the unit's image, and continue exploration from 
there using the "built-in" hypermedia links. Such a capabUity would facilitate 
implementation and integration of an interactive "unknown-unit-identifter" feature. 
Similar to that outlined in the ideal GEOTREC of Chapter IV. 

A further recommendation forthcoming from this research is that GEOTREC 
be designed in such a way that it could either be implemented as a standalone 


system, or integrated into computer systems which are currently in use in, or 
under development for, the Fleet. 

Concerning the standalone implementation, the recommended host for such a 
system is a workstation. Although today's top-of-the-Ime PCs are extremely 
capable in tenns of processing speed, primary memory capacity, and computational 
capabilities, they are still relatively limited in areas such as input/output (I/O) 
proficiency, particularly when compared to minicomputers and mainframes, "...in 


65 









terais of I/O capability and volume of external storage, microcomputers are far 
behind the mainframes, whereas for the processing capability and memory size the 
gap between the two types of computers is narrowing." ([Ref. 24], p.ll) Because 
a "standalone mainframe" is obviously inappropriate for this application, a 
workstation host could be the ideal middle ground, providing a significant increase 
in f/O performance over PCs, especially in the retrieval and display of graphical 
images so central to an application like GEOTREC. 

hi addition to improved I/O effectiveness, workstations provide larger, 
higher-resolution screens than do standard PC configurations, permitting more 
detailed, higher-resolution images to be displayed and manipulated. These larger 
screens, coupled with architectures which are designed for greater primary memory 
Utilization, allow workstations to provide more powerful windowing capabilities, 
perfect for hypermedia applications. Furthermore, increased primary memory will 
increase the effectiveness of gateways from the hypermedia software to other, 
related applications, without concern for the MS-DOS "640K" barrier. 

While a standalone GEOTREC would be suitable in many situations, the 
application should also, ideally, be integratable with Fleet systems such as JOTS 
(Joint Operational Tactical System), FDDS (Flag Data Display System), OBU 
(OSIS [Ocean Surveillance Information System] Baseline Upgrade), and NIPS 
(Naval Intelligence Processing System) 2000, to name a few. In such a setting, 
GEOTREC could augment the existing system’s capabilities by providing an on¬ 
line, hypermedia-based help and reference system. A typical scenario might take 
place in a FOSIC (Fleet Ocean Surveillance Information Center), where a watch 
officer, using OBU, receives a message on a new contact. To refresh his memory. 
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or to assist in preparing the next morning’s flag briefing, the watchstander clicks 
on the OBU-displayed symbol which corresponds to the new contact and an image 
of that unit appears in a window on the OBU screen, with embedded hypermedia 
links which allow the user to select the type and amount of related information he 
wishes to explore. 

A final recommendation of this thesis is that DOM-based threat recognition 
information of the type used in applications such as GEOTREC be published by 
appropriate naval and national intelligence organizations, such as DIA (Defense 
hitelligence Agency), NTIC (Naval Technical Intelligence Center), and the FICs 
(Fleet Intelligence Centers). For geographic information, DMA (the Defense 
Mapping Agency) already publishes a wide range of its products on DOM. 

Paper publications should not necessarily be discontinued, as they do present 
an alternative for situations in which computer-based solutions are not practicable. 
However, distributing this information on DOM would provide an alternative 
which is superior to paper publications in a myriad of ways. One such benefit 
would be that a greater number of alternate views of a particular threat unit (not 
to mention full-motion video) could be supplied on DOM, over and above what 
would be practical to include in comparable paper publications. These additional 
views would significantly improve the user’s perspective of how that unit will 
appear when seen in real life, leading to faster and more accurate threat 
recognition. 

In order to facilitate the production of DOM by appropriate agencies, an 
incentive program could be instituted to encourage users to send in theh locally- 
obtained or locally-developed digitized images, captured (e.g., scanned) on either 


67 













magnetic media or on WORM disks. TOs would provide a continuous source of 
"raw materials" in digitized form which could easfly be edited and coUated with 
other data into an updated DOM version. This updated DOM product could then 
be distributed (mote easily and at fer lower cost than paper) to aU concerned, 

providing Standardized, uniform dissemination throughout the Fleet. 

In conclusion, threat lecogniUon and geographical training ate fundamental 
parts of a requisite knowledge base for a large number of naval personnel who are 
assigned to operational or operations-oriented support billets. And yet readiness in 
these areas is often lacking, in large part due to the paucity of readily available, 
motivational instruction tools. The development and deployment of a system such 
as GEOTREC would not only provide an enjoyable, intuitive, yet challenging way 
to foster multi-sensory learning, but also a quick, powerful, and easy-to-use 
reference to needed information for a myriad of operational scenarios. 
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APPENDIX A: GEOTREC DEMONSTRATION 



This appendix is intended to demonstrate GEOTREC's user interface, 
menu hierarchy and hypermedia capabilities. Obviously, it is difficult, 
if not impossible, to express in a linear report such as this the full 
feel and features of non-linear hypermedia. To assist in this, the 
screens are accompanied by a running textual description, written as if 
the reader and writer were both sitting at the computer terminal, 
exploring GEOTREC together. 

After the user starts GEOTREC, he is required to login with a user 
identification (USERID) as shown above. If the USERID is valid, the 
system prompts for a password to provide further security. In either 
case, the system will allow only three attempts for each; otherwise, the 
user is advised to seek assistance from the System Administrator, and is 
returned to DOS. If the USERID/password are the System Administrator's 
the System Administrator's Menu (screen 2) is accessed; for any other 
valid user, the Main Menu (screen 4) is displayed. 























2 System Administrator's Menu 


- "1. Hyperdoc Tools"; provides access to all of the Hyperdoc object, 
graphic, text and other editors required to modify the Hyperdoc 
applrcation; 

^ "2. Scan a new image": calls the scanner device driver software, 
from which the scanner can be operated to digitize new images and save 
them on the hard disk; from there, the images can be converted to 
Hyperdoc format, via Hyperdoc Tools, for use in the application and/or 
for writing to a WORM disk for more permanent storage (this scanner 
control feature was not implemented in this prototype); 

- 3. Databases": calls the Database Gateway Menu (screen 3). 


^ Jhe System Administrator can access several functions not available 
to the ordinary user via the menu shown here, namely: 
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3 Database Gateway Menu, accessible from both the System 
Administrator's Initial Menu or the GEOTREC Main Menu. 


The Database Gateways Menu, shown here, can be accessed from either 
the System Administrator's Initial Menu (screen 2), or the from the Main 
Menu (screen 4). Database packages such as Paradox 3.0 and an Ingres 5.0 
application called the Threat Database’ can be accessed from th.is menu. 

Although not implemented in this application, the gateway mechanism 
would optimally provide the System Administrator access to the Database 
Management Systems (DBMS) packages with read and write privileges (e.g., 
by passing his USERID and password as parameters to the DBMS 
applications), while allowing read-only capabilities to all other users. 
This would prevent a separate, additional login to the DBMS application, 
as is presently required by the Threat Database (i.e., no mechanism exists 
for passing the USERID and password parameters from one application to 
another). 


’ The Threat Database was produced as a Naval Postgraduate School 
class project by Brad Triebwasser, Glenn Zeiders, and this author. 
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5 Maps and Charts Gateway Menu. 


The Maps/Charts Gateway Menu, shown here, is displayed upon the 
selection of "5. Maps/Charts gateway" from GEOTREC's Main Menu (screen 4). 
From this menu, the user can access applications which allow the display 
and manipulation of various maps and charts. FULCRUM, the only such 
application presently available from the GEOTREC prototype, is a system 
which was developed at the Naval Ocean Systems Center (NOSC), San Diego, 
California. 

Among a wide range of other functions, FULCRUM'S capabilities include 
the retrieval and display of digitized maps and charts which are stored 
on laserdiscs. FULCRUM allows the user to overlay annotations and data 
sets (e.g., unit positions, tracks, range circles/ellipses, and much more) 
on the geographic images, and would be invaluable as a geographic training 
and reference aid in the context of the GEOTREC application. 
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6 Main Menu after "1. Units/Weap.s/Sensors" option selected. 

Let us now return to the Main Menu (screen 4), and selprt iin 4 +c/ 
Weap.s/Sensors". As shown above, the user irorornDted to n^oL 
etter of the desired selection: UnUs' WeaK or Sen^orr tchoJ 

Sr-a iaSarai' 

these images would optimally be stored on CD-ROM or fas^erdiscs as 

to on the computer's hard disk as presently done as opposed 

scree^?.^""*^®" and move on to 









7 Unit Menu 


The Unit Menu, shown here, provides the user access to images of a 
wide variety of naval and navy-related units, ranging from aircraft to 
auxiliaries. Selecting "1. Aircraft" moves us on to screen 8. 
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8 Aircraft Menu 


In order to assist the user in making a selection, the Aircraft Menu 
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9 Bomber/Strike Aircraft Menu (initial) 


We have now reached the last stage of the system of menus, and are 
ready to begin viewing images. As with all menus on the "bottom layer" 
of the menu hierarchy, the Bomber/Strike Aircraft Menu, shown here, has 
several differences from the "higher" menus. 

First, Hyperdoc's menuing subsystem is used, as opposed to code- 
created menus, in order to accommodate long and possibly changing lists 
of units. With this Hyperdoc menuing subsystem, the user can no longer 
press a number or the first capitalized letter of the desired selection; 
instead, the user must use the mouse or up/down arrow keys the highlight 
the proper choice, and then click the left mouse button or press the ENTER 
key. Although this can be somewhat less convenient to users, it does 
allow for the menu listing to be longer than the screen display, in which 
case the unseen selections will scroll into view as the arrow keys or 
mouse attempt to move to highlight them. In addition, a convenient "move 
the menu" option is automatically added at the end of all Hyperddc menuing 
subsystem menus, allowing the user to view any portion of the screen that 
might be obstructed by the menu. 



























BONBERS/STRIKE niRCRflFI 


!NU : tgMriJ 




^ «.M it 




view ihri1n‘"app“™ ““'■ «Pt’'»'' ' 

sorted by either designator T*bi MTn^'r w'“'® So^et/Strike Aircraft 
Codename- the result is shown abw U^reenToT' select 'NA' 


IF we select 
















if' 



\ i s; f; M CJ M > i <■» 


rtnrr; U‘i ‘5 uavt 


I III ■• 11 rif^fii 








Previous r*em« FI = HeJu F2 = Brouser j 


Ri.nouse Burton or ESC 




BACKFitRl {Tu-22M) 


screen 


This image of a Tu-22m Backfire bomber is displayed in Hyperdoc's 
hypermedia mode invoked by the command "PROCESSDOC". In this mode, 
command nodes, known in Hyperdoc as objects, are associated ("linked") 
with certain locations ("hot spots", or "transparent buttons") on the 
image. If the user clicks with the mouse (as instructed at the top of the 
screen) on any of these buttons, the command that is linked to that 
location will be executed. In this case, the transparent button covers 
the entire fuselage of the aircraft (few other features are outstanding, 
due to the low image resolution forced by Hyperdoc's .PCX-only 
constraints). If we put the cursor on the fuselage and click the left 
mouse... (see next screen, screen 12) 
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15 Browser screen again, invoked after user has viewed multiple images. 


The browser does more than just map out the path taken by the user; 
n also allows the user to quickly return to any node in this "network" 
by simply clicking on that node. In this case, a click on the "TU-95 
braphique node brings up... (see next screen, screen 16) 
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...the image of the Tu-95 Bear aircraft previously viewed. From this 

oftfe ^ircraTt'^^^and on clicking, exploring additional features 

or ine aircraft, and calling up the browser (with the F2 key) whenever 

Unwnt ^ at any point during the browsing session 

will return the user to the Bomber/Strike Aircraft Menu (screen 9). 
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21 Screen displayed upon selection of Unit Menu 
choice "6. Merships". 


22 Screen displayed upon selection of Unit Menu 
choice "7. Other units". 
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24 One of the images randomly chosen for display, with the possible 
choices listed on the menu at right. 


The first randomly displayed image is shown here, with the list of 
possible choices from which the user can select overlaid in a menu on the 
right. Again, the user can move and resize the menu as necessary, even 
to the point where only one menu selection at a time is visible -- and yet 
all selections would still be available, simply by scrolling up or down 
with the mouse or arrow keys. 

The user is allowed three attempts to select the correct answer from 
the list of possible choices. If the user makes a correct selection on 
any of those three attempts, the following screen is displayed (see next 
screen, screen 25): 
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25 Screen after a correct selection made 
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26 Screen after three incorrect selection^^^^ attertlpts made. 

Whether the user makes a correct selection or three successive 
incorrect selections, he is given three options: 

- press Q to quit the Quizzer and return to the Initial Quizzer Menu 
(screen 23); 

- press M to get more information on the image being displayed; or, 

- go on to another randomly selected image (by pressing any key). 
Pressing M for More information will invoke Hyperdoc's hypermedia command 
"PROCESSDOC", as shown (see next screen, screen 27): 
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In addition to the label, a yellow Instruction box appears at the 
bottom of the screen, giving the user the option to press M for yet more 
Information on his selection, or any other key to return to the Image for 
further selections or exiting. If "M" Is pressed for more Information... 
(see next screen, screen 29) 
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28 Screen after user clicks on a major feature (In this case, oiie of 
the two small guns on the unit's aft end). 
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30 Screen after user clicks on hull of unit in image 


...a text box, describing the patrol boat, as shown here. Then, to 
get more information about the ADMG-630 (or any of the other features 
mentioned in the text box), the user would simply click on that word to 
see displayed... (see next screen, screen 31) 
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APPENDIX B: HYPERDOC ACTION FILES (CODE) 

A. LOGIN.YOB 

/* 1: start LOGIN */ 

@logintrys = 0; 

©sysadminvar « 0; 

%^LL, ••COMMON", 6;/*initiali2es vars for use in later menus*/ 
%CIjEARSCREEN, 10/*lt. green*/; 

%FONT, ••System4 8. fnt••; 

%DISTEXT, Swelcomewin, 135,85, 9/*black on It.blue*/, 

•• .11 ' ' 

•• WELCOME TO GEOTREC ••, , 

•' . 

%DISIX)C, "Tbilisil", "G", 0, 4, 0,0, 0/*bkgnd on white*/, 
70,60, 570,370; 

%FONT, "SystemOe.fnt"; 

%DISTEXT, @geotrecwin, 210,100, l/*white on blue*/, 

•• GEOTREC •• ; 

%FONT, ••System72. fnt" ; 

%DISTEXT, @spellitoutwin, 160,300, 2/* white on green */, 

•• the GEOgraphic and Threat RECognition ",, 

" training and reference tool 

/* userid block */ 


/* 2; enter userid */ 

%FONT, ••System72. fnt"; 

%QUESTTXTWIN, Suserid, 

•• Please type your USER ID and press ENTER; ", 120,400, 
4/*no.of spaces*/, l/*force uprcase*/, 9/*blk on It.blue*/; 
%CH0ICE, Suserid; /* list of valid userids */ 

/*"24 68"=Sys.Administrator*/ 
@logintrys = 0; 

%EXECUTE, "Login", 3; 

/* all other qualified users*/ 
@logintrys = 0; 

%EXECUTE, "Login", 4; 

§logintrys =0; 

%EXECUTE, "Login", 4; 

@logintrys = 0; 

%EXECUTE, "Login", 4; 

§logintrys = O; 

%EXECUTE, "Login", 4; 

@logintrys = 0; 

%EXECUTE, "Login", 4; 


%CASE= "2468": 

%CASE= ••ASDF": 
%CASE= "1234": 
%CASE= "A1B2": 
%CASE= "6789"; 
%CASE= "WXYZ": 
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%CASE= ''WWWW'': 


%CASE= 

%DEFAULT: 


}/* end CHOICE V 
%EXECUTE, "Login", 
END OBJECT 


@logintrys = O; 

%EXECUTE, "Login", 4; 

/* if entry left blank... */ 
%CALL, "Login", 6; 

/* if invalid entry made.. .*/ 
§logintrys = §logintrys +1; 

%IF, eiogintrys = 3; 

{ 

%CALL, "Login", 7; 

}/* end IF */ 

%ELSE; 

{ 

%CALL, "Login", 8; 

}/* end ELSE */ 


2 ; 


/* 3: enter Password (for SYSTEM ADMINISTRATOR) */ 

%FONT, "System72.fnt"; 

%QUESTTXTWIN, Spassword, 

" Please type your PASSWORD and press ENTER; ", 110,400, 
8/*# of spaces*/, l/*force uppercase*/, 9/*blk on It.blue*/; 
%CHOICE, &password; ^ 

{ 


%CASE= "DALILAMA": 


/*"DALILAMA"= Sys.Admin'or*/ 


%CASE= ""; 
%DEFAULT: 


)/* end CHOICE */ 
%EXECUTE, "Login", 
END_OBJECT 


@sysadminvar = l; 

%CL0SEWIN, @spellitoutwin; 

%CLOSEWIN, §geotrecwin; 

%EXECUTE, "SysAdmin", l; 

/*if entry left blank...*/ 
%CALL, "Login", 6; 

/*if invalid entry made.. .*/ 
@logintrys = §logintrys + 1; 

%IF, @logintrys = 3; 

{ 

%CALL, "Login", 7; 

}/* end IF */ 

%ELSE; 

{ 

%CALL, "Login", 9; 

}/* end ELSE */ 


3; 


/* 4: enter Password (for all other qualified users) */ 
%F0NT, "System72.fnt"; ' 
%QUESTTXTWIN, Spassword, 

" Please type your PASSWORD and press ENTER: ", lio,400. 
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8/*# of spaces*// l/*force uppercase*/, 14/*blk on yellow*/; 
%CHOICE, fipassword; 

{ 

/*A11 other qualified users*/ 
%CASE= "CAKEHOLE": %CALL, "Login", 5; 

%EXECUTE, "MainMenu", 1; 

%CASE= "SPAMSPAM": %CALL, "Login", 5; 

%EXECUTE, "MainMenu", 1; 

%CASE= "RATBAG": %CALL, "Login", 5; 

%EXECUTE, "MainMenu", 1; 

%CASE= "AMIGADOG": %CALL, "Login", 5; 

%EXECUTE, "MainMenu", 1; 

%CASE= "FOSTERS": %CALL, "Login", 5; 

%EXECUTE, "MainMenu", 1; 

%CASE= "HOSEHEAD": %CALL, "Login", 5; 

%EXECUTE, "MainMenu", 1; 

/*if entry left blank... */ 
%CASE= "": %CALL, "Login", 6; 

/*if invalid entry made.. .*/ 

%DEFAULT: eiogintrys = @logintrys + i; 

%IF, eiogintrys =3; 

{ 

%CALL, "Login", 7; 

}/* end IF */ 

%ELSE; 

{ 

%CALL, "Login", 9 ; 

}/* end ELSE */ 

)/* end CHOICE */ 

%EXECUTE, "Login", 4; 

END_OBJECT 

/* 5: Close windows */ 

%CLOSEWlN, @spellitoutwin; 

%CLOSEWIN, @geotrecwin; 

%RETURN; 

END_OBJECT 

/* 6: end GEOTREC */ 

%FONT, "System?2.fnt"; 

%DISTEXTSTOP, fiendgeotrec, 175,375, 8/*white on dark gray*/, 

" ENTRY CANNOT BE LEFT BLANK !I ",, 

" Press E to Exit GEOTREC, or ",, 

" any other key to continue. "; 

%CHOICE, &endgeotrec; 

{ 

%CASE= 69/*"E" in ASCII*/: %END;/*user ret'd to DOS*/ 
%DEFAULT/*any other key*/: %RETURN 7 
}/* end CHOICE */ 

END OBJECT 
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/* 7: error msg — too many login attemots */ 

%FONT, "Systemge.fnf; aT:T:empts */ 

%DISTpT, etoomanywin, 130,350, 4, /*red bkand*/ 
awiT'T UNSUCCESSFUL LOGIN ATTEMPTS! 

%FONT, ”System?2.fnt"; 

%DISTEXT esysadminwin, 130,385, 4, /*red bkgnd*/ 
%WAIT,, 2 . 5 ;^^^ System Administrator for help. 

%F0NT, "Systems6.fnt"; 

%WRITE, 220,440, 10/*lt.green ltrs*/»0/*black bkand*/ 

" NOW EXITING GEOTREC oxgnd*/, 

%WAIT,,2.5; 

%END; 

END_OBJECT 

/* 8: error msg ~ invalid userid */ 

%FONT, "System?2.fnt"; ' 

%DISTEXT, Sinvaliduseridwin, 180,375, 4/*white on red*/ 

again.", " 

%CLOSEWIN, Sinvaliduseridwin; 

%RETURN; 

END_OBJECT 

invalid password */ 

% FONT , "System? 2.fnt"; ' 

180,375, 4/*white on red*/, 
%WAIT 2 5 ^^ again."; ^ 

%CL0SEWIN, &invaliduseridwin; 

%RETURN; 

END_OBJECT 
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B. SYSADMIN.YOB 

/* 1: start SysAdmin */ 

%CALL, "COMMON", 6 ; /* set all var.s = 1 for next menus */ 
%CIiEARSCREEN, l/*blue bkgnd*/; 

%FONT, "System96.fnt"; 

%DISTEXT, etitlewin, 180,110, 14/*blac}c on yellow*/, 

" SYSTEM ADMINISTRATOR'S ",, 

" INITIAL MENU "; 

%FONT, "System24.fnt"; 

%DISTEXT, ipresswin, 197,210, ll/*black on It.azure*/, 

" Press number or first ",, 

" capital letter of ",, 

" desired selection: "; 

%F0NT, "System72.fnt"; 

%DISTEXTSTOP, fichoicevar, 205,256, 11/* black on It.azure */ 

" * 

" 1. Hyperdoc tools",, /* l = ASCII 49; H = ASCII 72 */ 

" 2. Scan a new image",, /* 2 = ASCII 50; S = ASCII 83 */ 

" 3. Databases ",, /* 3 = ASCII 51; D - ASCII 68 */ 

" 4. GEOTREC main menu",, /* 4 = ASCII 52; G = ASCII 71 */ 

" 5. Exit System Admin",, /* 5 = ASCII 53; E = ASCII 69 */ 

" •• • ' 

%CALL, "COMMON", 5; /* closes all windows */ 

@callerobj = "SysAdmin";/*so DBMSMENU'll know calling obi*/ 
%CHOICE, Schoicevar; - ■' ■ 

{ 


%CASE= 49: 
%CASE= 72: 


/* "1. Hyperdoc tools" */ 
/* "1^' in ASCII */ 
%EXECUTE, "SysAdmin", 2; 

/* "H" in ASCII */ 
%EXECUTE, "SysAdmin", 2; 


/* "2. Scan a new image"*/ 

%CASE- 50: /* » 2 » in ASCII */ 

%EXECUTE, "SysAdmin", 3; 

%CASE= 83: /* MS" in ASCII */ 

%EXECUTE, "SysAdmin", 3; 


/* "3. Databases" */ 

%CASE= 51: /* H 3 H in ASCII */ 

%EXECUTE, "DBMSMenu", 1 ; 

%CASE= 68 : /* "D" in ASCII */ 

%EXECUTE, "DBMSMenu", 1; 


/*"4. GEOTREC main menu"*/ 

%CASE- 52: /* "4" in ASCII */ 

%EXECUTE, "MainMenu", 1; 

%CASE= 71: /* HG" in ASCII */ 

%EXECUTE, "MainMenu", 1; 
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%CASE= 53: 

/* 

"5. Exit GEOTREC" 

/* 

"5" in ASCII */ 


%CALL, "COMMON", 4; 

%CASE= 69: 

/* 

"E" in ASCII */ 


%CALL, "COMMON", 4; 

%DEFAULT: 

/* 

Invalid selection 


%CALL, ''COMMON”, 3; 

}/* end CHOICE */ 

%EXECUTE, "SysAdmin", 1; 

END_OBJECT 

/* 2; Choice 1 "Hyperdoc tools" */ 

%DOSEXECUTE, "c:\\command.com", "/c", "c;\\hdtools.bat"; 
END_OBJECT 

/* 3: Choice 2 "Scan a new image" */ 

%DISTEXT, Sscanwin, 125,250, 7/*black on It. grey*/, 

" a SCANNER DRIVER will be called at this point "; 
%WAIT,,2.0; ^ 

%CLOSEWIN, Stscanwin; 

%EXECUTE, "SysAdmin", 1; 

END OBJECT 
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C. DBMSMENU.YOB 

/* 1: start DBMSMenu */ 

%CALL, "COMMON", 6 ; /* set all variables = 1 for next menus*/ 
%CLEARSCREEN, 12/*lt.red bkgnd*/; ' 

%FONT, "Systems 6 .fnt"; 

%DISTEXT, @titlewin, 185,135, l/*white on blue*/, 

" DATABASE GATEWAY MENU "; 

%FONT, "System2 4.fnt"; 

%DISTEXT, epresswin, 197,210, 9/*white on It.blue*/, 

" Press number or first ",, 

" capital letter of ",, 

" desired selection: "; 

%FONT, "System?2.fnt"; 

%DISTEXTSTOP, Schoicevar, 205,256, 9/*white on It.blue */. 

" 1. Threat (INGRES)",, /* 1 = ASCII 49; T = ASCII 84*/ 

2. Paradox 3.0",, /* 2 = ASCII 50; P = ASCII 80*/ 

3. <whatever>",, /* 3 = ASCII 51; */ 

" 4. Return to prev.menu",,/* 4 = ASCII 52; R = ASCII 82*/ 

» 5. Exit GEOTREC",, /* 5 = ASCII 53; E = ASCII 69*/ 


%CALL, "COMMON", 5; 
%CHOICE, Schoicevar; 


/* closes all windows */ 


%CASE= 49; 
%CASE= 84: 


/* "1. Threat (INGRES)"*/ 
/* "1" in ASCII */ 
%EXECUTE, "DBMSMenu", 2; 

/* "T" in ASCII */ 
%EXECUTE, "DBMSMenu", 2; 


%CASE= 50: 
%CASE= 80: 


/* "2. Paradox 3.0" */ 
/* "2" in ASCII */ 
%EXECUTE, "DBMSMenu", 3; 

/* "P" in ASCII */ 
%EXECUTE, "DBMSMenu", 3; 


%CASE= 51; 


/* "3. <whatever>"*/ 
/* "3" in ASCII */ 
%CALL, "GENERIC", 3; 

%EXECUTE, "DBMSMenu", 1; 


%CASE= 52: 
%CASE= 82: 


/ * " 4. Return to prev. menu " */ 
/* "4" in ASCII */ 
%EXECUTE, @callerobj, 1 ; 

/* "R" in ASCII */ 
%EXECUTE, @callerobj, 1 ; 


%CASE= 53: 


%CALL, "COMMON", 4; 


/* "5. Exit GEOTREC" */ 
/* "5" in ASCII */ 
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%CASE= 69: 


%CALL, ''COMMON", 


/* "E” in ASCII */ 
4; 


%DEFAULT: 

%CALL, "COMMON", 
)/* end CHOICE */ 

%EXECUTE, "DBMSMenu", 1; 

END OBJECT 


/* Invalid selection */ 
3; 


/* 2: Choice 1 "Threat (INGRES)" */ 
%DOSEXECUTE, "c:Wcommand.com", "/c", 
END OBJECT 


"c; Wingres. bat"; 


/* 3: Choice 2 "Paradox 3.0" */ 
%DOSEXECUTE, "c:Wcommand.com", "/c". 
END OBJECT 


"C: Wparadox. bat"; 
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D. MAINMENU.YOB 

/* 1: MainMenu */ 

%IF, @clearscreen =1; 

{ 

%CLEARSCREEN, 15/*white bkgnd*//* 

6clearscreen =0; 

}/* end IF V 
%IF, @dlsdoc =1; 

{ 

%DISDOC, ••Udal_Mag”, ”G»; 

@disdoc =0; 

}/* end IF V 

%FONT, " System9 6. fnt; 

%DISTEXT, ©titlewin, 365,45, 13/*black on It.magenta*/, 

" MAIN GEOTREC MENU ” 

•• II. 

%FONT, "System24.fnt"; 

%DISTEXT, ipresswin, 377,160, ll/*black on It.azure*/, 

•• Press number or first ”,, 

" capital letter of , 

" desired selection: 

%FONT, •'System72. fnt" ; 

%DISTEXTSTOP, Schoicevar, 380,206, ll/*black on It.azure*/, 

" 1. Units/Weap.s/Sensots",' /* i = ASCII 49; u = ASCII 85*/ 
" 2. recognition Quizzer" ,, /* 2 = ASCII 50; Q * ASCII 81 */ 

" 3. Databases gateway",, /* 3 = ASCII 51; D = ASCII 68*/ 

" 4. Maps/charts gateway",, /* 4 ASCII 52; M « ASCII 77*/ 
" 5. Identifier gateway",, /* 5 *= ASCII 53; I = ASCII 73*/ 

" 6. Exit GEOTREC",, /* 6 = ASCII 54; E = ASCII 69*/ 

" II. 

%CALL, "COMMON", 5; /*close all windows*/ 

@callerobj = "MainMenu";/*so DBMSMenu'll know calling obi . */ 
%CH0ICE, fichoicevar; 

/* "1. Us/Ws/Ss" */ 

%CASE= 49: /* "iH in ASCII */ 

%CALL, "MainMenu", 3; 

%CALL, "COMMON", 6;/* set vars to = 1 */ 
%EXECUTE, @uwsmenu, 1; 

%CASE= 85: /* HU" in ASCII */ 

%CALL, "MainMenu", 3; 

%CALL, "COMMON", 6;/* set vars to = 1 */ 
%EXECUTE, @uwsmenu, 1; 

/* "2. Recce Quizzer" */ 

%CASE= 50: /* 1*211 in ASCII */ 

§quizcalledbymain = 1 ; 

%EXECUTE, "Quizzer", 1; 
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%CASE= 81; 


%CASE= 51; 


%CASE= 68; 


%CASE= 52; 


%CASE= 77; 


%CASE= 53; 
%CASE= 73; 


%CASE= 54; 


%CASE= 69; 


%DEFAULT; 


^ /* "Q" in ASCII */ 

equizcalledbymain = 1 ; 

%EXECUTE, "Quizzer", 1 ; 

/*'* 3. Database gateway " */ 

/* Hoii A<;r'TT */ 

%CALL, "COMMON", 6;/* set vars to = i */ 
%EXECUTE , "DbmsMenu ", l; 

%CALL, COMMON", 6;/* set vars to = 1 */ 
%EXECUTE, "DbmsMenu", 1 ; ' 

/* "4. Maps gateway" */ 

%CALL, "COMMON", 6;/* set vars S = 1 */ 
%EXECUTE, "MapsMenu", l; ' 

/* "M" in AQPTT */ 

%CALL, "COMMON", 6;/* set varfto = 1 */ 
%EXECUTE, "MapsMenu", l; 

/*"5. Identifier gateway"*/ 

.. . /* i^ ASCII */ 

%CALL, "MainMenu" 4 ; 

s.m,TT • /* ASCII */ 

% CALL, "Ma inMenu",4; ^ 

/* "6. Exit GEOTREC" */ 

/* "6" in A^OTT */ 

%EXECUTE, "MainMenu", 2/*spec.exit confirm*//* 

/* "E" in ASCTT */ 

%EXECUTE, "MainMenu", 2/*spec.exit confirm*/; 


%CALL, "COMMON", 3; 
@clearscreen = O; 


/* Invalid selection */ 


)/* end CHOICE */ 

%EXECUTE, "MainMenu", l; 

END_OBJECT 

/ 2• special exit confirm ““ return to QVQimwTw ^/ 

%FONT, "System72.fnt"; return to SYSADMIN */ 

%QUESTTXTWIN, Sreply, 

SURE YOU WANT TO EXIT? (y/n)' " 1 sn 

uprcakv,'4/.^ln°UdV; 

( ^ ^ ^ user REALLY wants to exit...*/ 

«F, esysadmlnvar = 1 , /*lf user is Sys.Administrator,*/ 

)/*end^i?!^J®' !'• /‘return to SysAdmin menu.*/ 
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%ELSE; /* if user is NOT Sys.Admin, */ 

{ 

%END; /* exit from GEOTREC.*/ 

}/*end else*/ 

)/*end if*/ 

%EIiSE; /*if user DOESN'T wanna exit...*/ 

{ 

§clearscreen =0; 

%EXECUTE, "MainMenu", 1; /* return to MainNenu*/ 

}/*end else*/ 

END_OBJECT 

/* 3: Units/Weap.s/Sensors choice */ 

%DISTEXTSTOP, &uwschoice, 385,160, 13/*black on It.magenta*/, 

" PLEASE PRESS: ",, 

" - U for Unit menu",, /* U = ASCII 85 */ 

" - W for Weapons menu",,/* W = ASCII 87 */ 

" - S for Sensors menu",,/* S = ASCII 83 */ 

" (any other key to",, 

" return to Main menu) ",, 

It II • 

%CH0ICE, fiuwschoice; 

{ 

%CASE= 85: @uwsmenu = "UnitMenu"; 

%CASE= 87: @uwsmenu = "WeapMenu"; 

%CASE= 83: @clearscreen - 1; 

%CALL, "GENERIC", 3; 

%EXECUTE, "MainMenu", 1; 

%DEFAULT: %EXECUTE, "MainMenu", 1; 

}/* end CHOICE */ 

%RETURN; 

END_OBJECT 

/* 4: in lieu of Identifier gateway */ 

%DISTEXTSTOP, fiidgatewaywin, 175,175, 13/*blk on It.magenta*/, 
" ...at this point, a gateway would be called, ",, 

" starting an application which would assist in ",, 

" identifying unknown units via an interactive ",, 

" Query/Response session with the user... ",, 

" PRESS ANY KEY TO CONTINUE "; 

%CHOICE, fiiidgatewaywin; 

{ 

DEFAULT: %RETURN; 

}/* end CHOICE */ 

END OBJECT 
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E. NAPSMENU.YOB 

/* 1: start MapsMenu */ 

%CALL, "COMMON", 6; /* set all i ^ 

%CLEARSCREEN, li/*;hestnut bkgnd*/? 

%FONT, "Systein96.fnt"; ' 

%DISTEXT, etitlewin, 175,135, 0/*white on black*/ 

MAPS/CHARTS GATEWAY MENU "; '' 

%FONT, "Systein24. fnt"; 

%DISTEXT Jpresswln, 197,210, 15/*blaok on White*/, 

Press number or first ", ^ 

'• capital letter of ", \ 

” desired selection: 

%FONT, "System?2. fnt"; 

%DISTEXTSTOP, fichoicevar, 205,256, 15/*black on white */, 

;; 4. Rr-t^rrtTprev.menu",,/* 4^ = ASC?/52 ^.'*r*- ASCII 82*/ 
;; 5. Exit GEOTREC", , '5 = aIc^ 531 E I aIc^I 11// 

%CALL, "COMMON", 5; ' /* . 

%CH0ICE, Schoicevar* ' closes all windows*/ 

r ^ 


%CASE= 49; 

%CASE= 70; 

/* "1. FULCRUM" */ 

/* M^" in ASCTT */ 

%EXECUTE, "MapsMenu", 2; ^ 

3,„vr.«rTmr7 .. /* ASCII */ 

%EXECUTE, "MapsMenu", 2; 

%CASE= 50: 

/* "2. Paradox 3 . 0 " */ 

.. /* "2” in ASCII */ 

%CALL, "GENERIC", 3; / 

%EXECUTE, "MapsMenu", 1 ; 

%CASE= 51; 

/* "3. <whatever>"*/ 

o.„,Tx .. /* in ASCII */ 

%CALL, "GENERIC", 3; ' 

%EXECUTE, "MapsMenu", 1 ; 

%CASE= 52: 

%CASE= 82: 

/*"4.Return to prev.menu"*/ 
%EXECUTE, ..MeinMenuC T “ 

%EXEC«TE, "MalnMenuC T 


%CASE= 53; 
%CASE= 69: 


%CALL, "COMMON", 4; 


/* "5. Exit GEOTREC" */ 
/* "5" in ASCII */ 

/ 

/* "E" in ASCII */ 
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%CALL, •• COMMON”, 4; 


%DEFAULT: /* Invalid selection */ 

%CALL, "COMMON”, 3; 

)/* end CHOICE */ 

%EXECUTE, "MapsMenu”, 1; 

END_OBJECT 

/* 2: Choice 1 "FULCRUM” */ 

%DOSEXECUTE, ”c:\\conimand.com”, ”/c”, "c:\\fulcrum.bat”; 

END OBJECT 
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UNXTMENU.YOB 


/* 1: Unit Menu */ 

%IF, §clearscreen = l; 


{ 


%CLEARSCREEN, 15/*white bkgnd*/; 
eclearscreen = O; 


%IF, edisdoc = 1 ; 
{ 


} 

%FONT, "System2 4 . fnt'•; 

%WRITE, 2^470^15/*white Itrs.*/, 8/*dk.grey bkgnd*/, 

MENU LEVEL; Main —> UNIT", ^ / 

ft • 

/* only if called from above */ 

%DISDOC,^..Tarantul», ‘lO-O, 15/*blk cn bbgndv, 

@disdoc = 0; 

}/* end IF */ 

% FONT, "System9 6.fnt"; 

%DISTEXT, on blue./, 

%FONT, "System24.fnt"; 

%DISTEX^ gpresswin, 206,145, 10/*black on It.green*/. 

Press number or first " ^ > 

" capital letter of "^ | 

" desired selection; 

%F0NT, "System72.fnt"; 

%DISTEXTSTOP, tohoioevar, 205,191, 10/*blaok on It.green*/. 


/ / 


" 2* aSS^^ 'n - , /* 1 “ ASCII 49; 
II Carriers",,/* 2 = ASCII 50; 
II I' combat ant s",,/*3 = ASCII 51; 
II r .. /* 4 = ASCII 52; 


A 
C 
S 

5 . auxiliary-ships",, 5 = aIc^ 53! v 

" «• "etchant ships*,, ;* 6 » JgJ I4; M 

" 8* Retu^n^?i^^ " /* 7 = ASCII 55; 

.. « prev.menu", ,/*8= ASCII 56* 

:: GEOTREC*,, g; 


o 

R 

E 


ASCII 65 */ 
ASCII 67 */ 
ASCII 83 */ 
ASCII 85 */ 
ASCII 88 */ 
ASCII 77 */ 
ASCII 79 */ 
ASCII 82 */ 
ASCII 69 */ 


%CALL, "COMMON", 5; ' /* „i . 

WHOWEfioholoetar^"”’^* ^lUng^bJelt**/ 

{ 


%CASE= 49; 
%CASE= 65; 


/* " 1 . Aircraft" */ 
eets'^va^gj *^l */ 

%EXECUTE, "Aircraft", 1 ; ■' 

9.0*TX .. /* ASCII */ 

%CALL, "COMMON", 6;/* sets vars to =1 */ 
%EXECUTE, "Aircraft", i; 
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%CASE= 50: 


%CASE= 67 

%CASE= 51: 
%CASE= 83: 

%CASE= 52: 
%CASE= 85: 

%CASE= 53: 
%CASE= 88: 

%CASE= 54: 
%CASE= 77: 

%CASE= 55: 
%CASE= 79: 

%CASE= 56: 


/* "2. aircraft Carriers"*/ 
„ /* "2" in ASCII */ 

%CALL, "COMMON", 6;/* sets vars to = i */ 

%EXECUTE, "Carriers", 1 ; ' 

. _ /* "C" in ASCII */ 

%CALL, "COMMON", 6;/* sets vars to = 1 */ 

%EXECUTE, "Carriers", i; ' 

/*"3. Surface combatants"*/ 

/* "3" in ASCII */ 

%CALL, "COMMON", 6;/* sets vars to = l */ 

%EXECUTE, "SurfComb", l; ^ 

/* "S" in ASCII */ 

%CALL, "COMMON", 6;/* sets vars to = l */ 

%EXECUTE, "SurfComb", 1 ; ^ 


/* "4. submarines" */ 

.. /* in ASCII */ 

%CALL, "COMMON", 6;/* sets vars to = l */ 
%EXECUTE, "Subs", 1; ' 

.. /* in ASCII */ 

%CALL, "COMMON", 6;/* sets vars to =1 */ 
%EXECUTE, "Subs", 1 ; ^ 


/* "5. auxiliary ships" */ 
« /* "5*' in ASCII */ 

6;/* sets vars to =* i */ 
%EXECUTE, "Auxils", 1; 


%CALL, " 
%EXECUTE 


/* MX" in A^CTT 
COMMON", 6;/* sets vars to 
/ "Auxils", 1 ; 



*/ 


%CALL, " 
%EXECUTE 


/* "6. Merchant ships" */ 
/* "6" in ASCII */ 
COMMON", 6;/* sets vars to = 1 */ 

, "Merships", l; 


"COMMON", 6;/* sets vars to = i */ 
%EXECUTE, "Merships", 1 ; ^ 


%CALL, " 
%EXECUTE 


/* '• 
/* 

COMMON", 6;/* 
, "GENERIC", 


7. Other units" 
"7" in ASCII * 
sets vars to = 
1 ; 


/ 


*/ 

1 */ 


/* 

%CALL, "COMMON", 6;/* 
%EXECUTE, "GENERIC", 


"O" in ASCII 
sets vars to 
1 ; 



*/ 


/*"8.Return to prev.menu"*/ 
/* "8" in ASCII */ 
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%CASE= 82: 


@clearscreen = i; 

%EXECUTE, "MainMenu", 1; 

/* "R" in ASCII */ 

@clearscreen =1; 

%EXECUTE, "MainMenu", l; 


%CASE= 57: 

%CALL, "COMMON”, 

/* "9. Exit 
/* "9" in 
4; 

GEOTREC" */ 
ASCII */ 

%CASE= 69: 


/* "E" in 

ASCII */ 


%CALL, "COMMON", 

4; 

%DEFAULT: 

%CALL, "COMMON", 

/* Invalid selection*/ 
3; 


}/* end CHOICE */ 
%EXECUTE, "UnitMenu", 1; 
END OBJECT 
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6. AIRCRAFT.YOB 
/* 1: Aircraft */ 

%IF, @clearscreen * 1; 


%CLEARSCREEN, 9/*lt.blue bkgnd*/; 
iclearscreen = 0; 


> 

%FONT, •'System24. fnt" ; 

%WRITE, 20,470, 15/*white Itrs.*// 8/*dk.grey bkgnd*// 

" MENU LEVEL: Main —> Unit —> AIRCRAFT ”, 

» II. 

%IF, @disdoc = 1; /* only if called from above*/ 

%DISDOC, ”Forger_l”, ”G”, 1,1, o,0, 0/*bkgnd on white*/, 
50,10, 590,300; 

@disdoc =0; 


}/* end IF */ 

%FONT, "System96.fnt”; 

%DISTEXT, @menuwin, 215,25, 2/*black on green*/, 

” AIRCRAFT ”; 

%FONT, "System24.fnt”; 

%DISTEXT, @presswin, 330,220, 10/*black on It.green*/, 

” Press number or first ”,, 

” capital letter of ”,, 

” desired selection: ”; 

%FONT, ”System72.fnt"; 

%DISTEXTSTOP, fichoicevar, 333,266, 10/*black on It.green*/, 

” li 


" 1. Bombers/strike",, 

” 2. Fighters",, 

" 3. Helicopters",, 

" 4. MPA/ASW/recon/EW",, 

" 5. Other",, 

” 6. Return to prev.menu”,, 
" 7. Exit GEOTREC”,, 


/* 1 = ASCII 49; B » ASCII 66*/ 
/* 2 * ASCII 50; F = ASCII 70*/ 
/* 3 = ASCII 51; H = ASCII 72*/ 
/* 4 = ASCII 52; M = ASCII 77*/ 
/* 5 = ASCII 53; 0 = ASCII 79*/ 
/* 6 = ASCII 54; R = ASCII 82*/ 
/* 7 = ASCII 55; E = ASCII 69*/ 


%CALL, "COMMON”, 5; /* close all windows */ 

§callerobj = "Aircraft”;/* so GENERIC knows calling object */ 
%CHOICE, &choicevar; j / 

{ 


%CASE= 49: 
%CASE= 66: 

%CASE= 50: 


/* ”1. Bombers/strike” */ 
/* ”1" in ASCII */ 

%CALL, "COMMON”, 6;/* sets vars to = l */ 
%EXECUTE, "BombStk”, 1 ; 

/* "B" in ASCII */ 

%CALL, "COMMON”, 6;/* sets vars to = l */ 
%EXECUTE, "BombStk", 1; 

/* "2. Fighters" */ 

/* ”2” in ASCII */ 

%CALL, "COMMON”, 6;/* sets vars to = 1 */ 
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%CASE= 82 


@clearscreen = 1; 

%EXECUTE, "MainMenu", 1; 

/* ''R'' in ASCII */ 

@clearscreen =1; 

%EXECUTE, "MainMenu'', 1; 

/* '*9. Exit GEOTREC" */ 


%CASE= 57: 

%CALL, 

"COMMON”, 

/* "9" in ASCII V 

4 r 

%CASE= 69: 

%CALL, 

"COMMON", 

/* "E" in ASCII V 

4; 

%DEFAULT: 



/* Invalid selection*/ 


%CALL, 

"COMMON", 

3; 


}/* end CHOICE */ 
%EXECUTE, "UnitMenu", 1; 
END OBJECT 
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G. AIRCR21FT.Y0B 
/* 1: Aircraft */ 

%IF, @clearscreen =1; 

{ 

%CLEARSCREEN, 9/*lt.blue bkgnd*/; 

@clearscreen = 0; 

} 

%FONT, ''Systein24.fnt''; 

%WRITE, 20,470, 15/*white ltrs.*/f 8/*dk.grey bkgnd*// 

" MENU LEVEL: Main —> Unit —> AIRCRAFT ", 

•• . 

r 

%IF, §disdoc =1; /* only if called from above*/ 

{ 

%DISDOC, "Forger_l", ”G", 1,1, 0,0, 0/*bkgnd on white*/, 
50,10, 590,300; 

@disdoc =0; 

}/* end IF */ 

%FONT, ”System96.fnt"; 

%DISTEXT, @menuwin, 215,25, 2/*black on green*/, 

" AIRCRAFT "; 

%FONT, "System24.fnt''; 

%DISTEXT, @presswin, 330,220,.10/*black on It.green*/, 

" Press number or first ”,, 

" capital letter of ”,, 

" desired selection: 

%F0NT, "System72.fnt"; 

%DISTEXTSTOP, &choicevar, 333,266, 10/*black on It.green*/, 

” 1. Bombers/strike",, " /* 1 = ASCII 49; B = ASCII 66*/ 

" 2. Fighters”,, /* 2 = ASCII 50; F = ASCII 70*/ 

" 3. Helicopters",, /* 3 = ASCII 51; H = ASCII 72*/ 

" 4. MPA/ASW/recon/EW”, , /* 4 = ASCII 52; M = ASCII 77*/ 

” 5. Other”,, /* 5 = ASCII 53; O = ASCII 79*/ 

" 6. Return to prev.menu",, /* 6 = ASCII 54; R = ASCII 82*/ 

” 7. Exit GEOTREC",, /* 7 = ASCII 55; E = ASCII 69*/ 

•' II. 

%CALL, "COMMON", 5; /* close all windows */ 

@callerobj = "Aircraft";/* so GENERIC knows calling object */ 
%CHOICE, Schoicevar; 

{ 

/* "1. Bombers/strike" */ 

%CASE= 49: /* »i» in ASCII */ 

%CALL, "COMMON", 6;/* sets vars to = 1 */ 
%EXECUTE, "BombStk", 1; 

%CASE= 66: /* "B" in ASCII */ 

%CALL, "COMMON", 6;/* sets vars to = 1 */ 
%EXECUTE, "BombStk", 1; 

/* "2. Fighters" */ 

%CASE= 50: /* •• 2 " in ASCII */ 

%CALL, "COMMON", 6;/* sets vars to = 1 */ 
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%CASE= 70: 


%CASE= 51: 

%CASE= 72: 


%EXECUTE, "Fighters", 

/* 

%CALL, "COMMON", 6 ;/* 
%EXECUTE, "Fighters", 

/* 

/* 

%CALL, "COMMON", 6 ;/* 
%EXECUTE, "Helos", 1; 

/* 

%CALL, "COMMON", 6 ;/* 
%EXECUTE, "Helos", 1; 


1 ; 

"F" in ASCII */ 
sets vars to = 1 */ 
1 ; 

"3. Helicopters" */ 
"3" in ASCII */ 
sets vars to = 1 */ 

"H" in ASCII V 
sets vars to = 1 */ 


%CASE= 52: 

/* 

%CASE= 77: 


/* 


%CASE= 53: 


/* 


/* "4. MPA/ASW/recon/EW" */ 
/* "4" in ASCII */ 

%CALL, "COMMON", 6 ;/* sets vars to = 1 */ 
%EXECUTE, "GENERIC", 1; 

%EXECUTE, "MPAASWEW", 1;*/ 

/* "M" in ASCII */ 

%CALL, "COMMON", 6;/* sets vars to = 1 */ 
%EXECUTE, "GENERIC", 1; 

%EXECUTE, "MPAASWEW", 1;*/ 

/* "5. Other" */ 

/* "5" in ASCII V 

%CALL, "COMMON", 6 ;/* sets vars to = 1 */ 
%EXECUTE, "GENERIC", 1; 

%EXECUTE, "OthrAcft", 1;*/ 


%CASE= 79: 


/* 


/* "0" in ASCII */ 

%CALL, "COMMON", 6 ;/* sets vars to = 1 */ 
%EXECUTE, "GENERIC", 1; 

%EXECUTE, "OthrAcft", 1;*/ 


/*" 6 .Return to prev.menu"*/ 
%CASE= 54: /* " 6 " ill ASCII */ 

@clearscreen = 1 ; 

%EXECUTE, "UnitMenu", 1; 

%CASE= 82: /* "R" in ASCII */ 

@clearscreen = 1 ; 

%EXECUTE, "UnitMenu", 1; 


%CASE= 55: 
%CASE= 69: 
%DEFAULT: 


%CALL, "COMMON", 

%CALL, "COMMON", 

%CALL, "COMMON", 
@clearscreen = 0 


}/* end CHOICE */ 


/* 

"7. 

Exit GEOTREC 

/* 

II -7 II 

in ASCII 

*/ 

/* 

"E" 

in ASCII 

*/ 


4 ; 

/* Invalid Selection */ 
3; 
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H. BOMBSTK.YOB 
/* 1: Bombstk */ 

%IF, @clearscreen =1; /* only if called from above*/ 

^ %CLEARSCREEN, 14/*yellow bkgnd*/; 

@clearscreen =0; 

}/* end IF */ 

%FONT, "System24.fnt”; 

%WRITE, 20,470, 15/*white Itrs*/, 8/*dk.grey bkgnd*/, 

" MENU LEVEL: Main —> Unit —> Aircraft —> " 
"BOMBER/STRIKE ACFT ”; 

%IF, @disdoc =1; /* only if called from above*/ 

^ %DISDOC, ''Blackj_l", "G”, 0, 4, 0,0, 15/*black on bkgnd*/, 
100,45, 545,285; 

@disdoc = 0; 

}/* end IF */ 

%CALL, "COMMON", 1; /* mouse instructions */ 

%FONT, "System72.fnt"; 

%MENU, Sesortvar, 200, 270, l/*default choice*/, 

" LIST AIRCRAFT NAMES SORTED BY; ", 

"DESIGNATOR ", /* Choice 1 */ 

"NATO CODENAME", /* choice 2 */ 

II- 11 ^ /* separator */ 

"[return to previous menu]", /* choice 4 */ 

"[exit GEOTREC]"; /* choice 5 */ 

%CHOICE, &sortvar; 

{ 

%CASE= 1: %EXECUTE, "BombStk", 2; 

%CASE= 2: %EXECUTE, "BombStk", 3; 

%CASE= 4: @clearscreen = 1; 

%EXECUTE, "Aircraft", 1; 

%CASE= 5: %CALL, "COMMON", 4; 

%DEFAULT; %CALL, "COMMON", 3; 

)/* end CHOICE */ 

%EXECUTE, "BombStk", 1; 

END_OBJECT 

/* 2: Menu, SORTED BY DESIGNATOR */ 

%IF, @clearscreen = 1; 

{ 

%CLEARSCREEN, 14/*yellow bkgnd*/; 

%CALL, "COMMON", 1; /* mouse instructions*/ 

}/* end IF */ 

%FONT, "System24.fnt"; 

%WRITE, 20,470, 15/*white Itrs*/, 8/*dk.grey bkgnd*/, 

" MENU LEVEL: Main —> Unit —> Acft —> " 

"Bmb/Stk —> BY DESIGNATOR"; 

%FONT, "System72.fnt"; 
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%MENU, fichoicevar, 205,125, 5/*default 
'• BOMBERS/STRIKE AIRCRAFT ”, 

" - SORTED BY DESIGNATOR - ”, 


"[return to previous menu]”, 
"[exit GEOTREC]”, 

••-II 

"Tu-16 Badger C/G”, 

"Tu-22 Blinder ”, 

”TU“22m Backfire ”, 

"Tu-95 Bear B/C ”, 

"Tu-160 Blackjack ”, 

II___II. 

%FUNCTIONKEY, "ESC”, "BombStk”, 2; 
%CHOICE, Schoicevar; 


/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 


choice*// 


choice 2 */ 
choice 3 */ 
separator */ 
choice 5 */ 
choice 6 */ 
choice 7 */ 
choice 8 */ 
choice 9 */ 
separator */ 


{ 


%CASE= 2: 


/* ”[Return to prev.menu]"*/ 
%EXECUTE, "BombStk”, 1; 


/* 


/* 


%CASE= 3: 


%CASE= 5: 


%CASE= 6: 


%CASE= 7: 


%CASE= 8: 


/* "[Exit GEOTREC]” */ 

%CALL, "COMMON”, 4; 

@clearscreen = 0; 

/* ”Tu-16 Badger C/G” */ 
%CALL, "GENERIC", 3; 

@clearscreen =1; 

%CALL, "COMMON”, 2; 

@clearscreen =1; 

%PR0CESSD0C, ”Badger_l”, ”G”, 1, 1, 0,0, 

1 *color* , 50,45, 620,460;*/ 

/* "Tu-22 Blinder” */ 
%CALL, "GENERIC”, 3; 

@clearscreen =1; 

%CALL, "COMMON", 2; 

§clearscreen =1; 

%PROCESSDOC, "Blinderl", ”G”, 1, 1, 0,0, 

1 *color* , 50,45, 620,460;*/ 

/* ”Tu-22m Backfire" */ 

%CALL, "COMMON", 2; 

@cl6arscreen = 1; 

%PROCESSDOC, ”Backf_l”, "G", 1, 1, 0,0, 
l/*color*/, 70,140, 570,315; 

/* "Tu-95 Bear B/C" */ 

%CALL, "COMMON", 2; 

@clearscreen =1; 

%PROCESSDOC, "TU95”, ”G”, 1, 1, 0,0, 
l/*color*/, 10,90, 630,370; 


%CASE= 9: 


/* "Tu-160 Blackjack" */ 









%CALL, "COMMON'', 2; 
eclearscreen = 1; 

%PROCESSDOC, "Blackj_l", "G", 1, 4, 0,0, 
l/*COlor*/f 75,50, 540,300; 

%DEFAULT: /* Invalid selection */ 

%CALL, "COMMON", 3; 
eclearscreen =0; 

}/* end CHOICE */ 

%EXECUTE, "BombStk", 2; 

END OBJECT 


/* 3: Menu, SORTED BY NATO CODENAME */ 

%IF, eclearscreen = 1; 

^ %CLEARSCREEN, 14/*yellow bkgnd*/»* 

%CALL, "COMMON", 1; /* mouse instruct.s*/ 

}/* end IF */ 

%F0NT, "System24.fnt"; 

%WRITE, 20,470, 15/*white ItrsVf 8 /*dk.grey bkgnd*// 

" MENU LEVEL: Main —> Unit —> Acft —> Bmb/Stk —> " 
"BY CODENAME 
%FONT, "System72.fnt"; 

%MENU, Schoicevar, 205,125, 5/*default 
" BOMBERS/STRIKE AIRCRAFT ", 

SORTED BY NATO CODENAME 
"[return to previous menu]", /* 

"[exit GEOTREC]", /* 

•I-/* 

"Backfire (Tu“22m) ", /* 

"Badger C/G (Tu-16)", /* 

"Bear B/C (Tu-95) ", /* 

"Blackjack (Tu-160)", /* 

"Blinder (Tu-22) ", /* 

II_M; /* 

%FUNCTIONKEY, "ESC", "BombStk", 3; 

%CHOICE, Schoicevar; 

%CASE= 2: /*"[Return to prev.menu]"*/ 

%EXECUTE, "BombStk", 1; 


choice*// 


choice 2 */ 
choice 3 */ 
separator */ 
choice 5 */ 
choice 6 */ 
choice 7 */ 
choice 8 */ 
choice 9 */ 
separator */ 


%CASE= 3: 


%CASE= 5: 


%CASE= 6: 


/* "[Exit GEOTREC]" */ 

%CALL, "COMMON", 4; 
eclearscreen = 0; 

/* "Backfire (Tu-22m)" */ 
%CALL, "COMMON", 2; 
eclearscreen =1; 

%PROCESSDOC, "Backf_l", "G", 1, 1, 0,0, 
l/*color*/, 70,140, 570,315; 

/* "Badger C/G (Tu-16)" */ 
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%CASE= 7: 


%CASE= 8 : 


%CASE= 9: 


%DEFAULT: 


%CALL, "GENERIC", 3; 

@clearscreen == l; 

%CALL, "COMMON", 2; 

@clearscreen = l; 

%PROCESSDOC, "Badger_l", "G", 1 , l, o 0 
1 *color* , 50,45, 620,460;*/ ' ' ' 

/* "Bear B/C (Tu-95)" */ 
%CALL, "COMMON", 2; v ; / 

§clearscreen = l; 

%PROCESSDOC, "TU95", "G". 1100 
l/*Color*/, 10,96, 636,370/ 

/* "Blackjack (Tu-160)" */ 
%CALL, "COMMON", 2; ^ ' 

@clearscreen = 1 ; 

%PROCESSDOC, "Blackj_l", "G", 1400 
l/*Color*/, 75,50, 540,300; ' ' ' 

/* "Blinder (Tu- 22 )" */ 
%CALL, "GENERIC", 3; ^ 

@clearscreen = 1 ; 

%CALL, "COMMON", 2; 

@clearscreen = l; 

%PROCESSDOC, "Blinderl", "G", l l 0 0 
1 *COlor* , 50,45, 620,460;*/ ' ' ' 

/* Invalid Selection */ 

%CALL, "COMMON", 3; 

@clearscreen = 0 ; 


}/* end CHOICE */ 

%EXECUTE, "Bombstk", 3; 

END_OBJECT 

/* 4; Backfire text */ 

@clearscreen = i; 

%PROCESsroG,^"Backfire", «T.., i,i, o,o, lo/.blk on It.green*/, 
END_OBJECT 

/* 5: AS -4 on Backfire (underside) */ 

eclearscreen = 1 ; ' 

%PROCESSDOC, '•Backf_2", "G", 1,1, 0,0, l/*oolor*/, 

115,115, 475,350; ' 

END_OBJECT 

/* 6: AS-15 text */ 

@clearscreen = 1 ; 

%PROCESSDOC, "AS15". "T" 11 on i n-la. 

75 , 25 , 590,200; ' ' ' ' It.green*/, 

end object 


/* 7: Blackjack text */ 
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%DISTEXT, Seblackjwin, 15,15,15, ^ 

'• This is an artist's conception of a Tu-160 Blackjacjc. 


II 


%WAIT,,3.0; 

%CLOSEWIN, Stblackjwin; 
END OBJECT 
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I. FIGHTERS.YOB 
/* 1: Fighters */ 

%IF, @clearscreen =1; 

{ 

%CLEARSCREEN, 10/*lt.green bkgnd*/; 
eclearscreen = 0 ; 

}/* end IF */ 

%FONT, "Systein24.fnt"; 

ItrsV, 8 /*dk.grey bkgnd*/, 

_ MENU LEVEL. ^ Mam —> Unit —> Aircraft —> FIGHTERS ", 
%IF, Qdisdoc = 1 ; 

l=/*Waok on bkgnd*/, 

@disdoc = 0 ; 

}/* end IF */ 

%CALL, "COMMON” 1 • /x _ . . 

%F 0 NT, "System72.fAt»; instructions */ 

%MENU Ssortvar, 200 , 270, l/*default choice*/, 

LIST AIRCRAFT NAMES SORTED BY: " 

"NA TO CO DENAME^,^^ ^Joioe 1 ^/ 

"[return to previous menu]", /* choict^T^iY 

"[exit GEOTRECl"; V* t J, 

%CH0ICE, fisortvar; ^ choice 5 */ 

{ 

- %EXECUTE, "Fighters", 2 ; 

%EXECUTE, "Fighters", 3 ; 

%CASE— 4: §clearscreen *= i; 

%EXECUTE, "Aircraft", l; 

%CASE- 5: %CALL, "COMMON", 4 ; 

%DEFAULT: %CALL, "COMMON", 3 ; 

}/* end CHOICE */ 

%EXECUTE, "Fighters", l; 

END_OBJECT 

/* 2: Menu, SORTED BY DESIGNATOR */ 

%IF, §clearscreen = l; ' 

{ 

green bkgnd*/; 

)/* enfl^*;^"”™"' '-■ /* Instructions */ 

%F 0 NT, "Systein24.fnt"; 

%WRITE,^^4^ iy*white itrs*/, 8 /*dk.grey bkgnd*/, 

"-> BY DESIGNATORS;”^ -> Fighters ", 

%F 0 NT, "Systein72.fnt"; 

%MENU, Schoicevar, 210,100, 5/*default choice*/, 


11 
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” FIGHTER AIRCRAFT ”, 

” - SORTED BY DESIGNATOR - ”, 
”rreturn to previous menu]”. 

/* 

choice 2 */ 

"[exit GEOTREC]”, 

, _ 

.11 

9 

/* 

/* 

choice 3 */ 
separator */ 

"MiG-23 Flogger 

tt 

9 


/* 

choice 5 */ 

"MiG-25 Foxbat 

It 

9 


/* 

choice 6 */ 

"MiG-29 Fulcrum 

M 

9 


/* 

choice 7 */ 

"MiG-31 Foxhound 

II 

9 


/* 

choice 8 */ 

"Su-20 Fitter 

II 

9 


/* 

choice 9 */ 

"Su-24 Fencer 

II 

9 


/* 

choice 10 */ 

"Su-25 Frogfoot 

II 

9 


/* 

choice 11 */ 

"Su-27 Flanker 

II 

9 


/* 

choice 12 */ 

"Yak-38 Forger 

II 

9 


/* 

choice 13*/ 


— 

.11 • 

9 

/* 

separator */ 


%FUNCTIONKEY, ''ESC, "Fighters”, 2; 
%CHOICE, Schoicevar; 


%CASE= 2: 

/* ”[Return to 

prev.menu]”*/ 


%EXECUTE, "Fighters", 1; 


%CASE= 3: 

/* "[Exit 

GEOTREC]" */ 


%CALL, "COMMON”, 4; 



@clearscreen = 0 ; 


%CASE= 4: %CALL, "COMMON”, 3;/* Invalid Selection */ 

@clearscreen * 0 ; 


%CASE= 10: 


%CASE= 12: 


%CASE= 13: 


%CASE= 14: 


/* "Su-24 FENCER” */ 

%CALL, "COMMON”, 2; 

@clearscreen = 1 ; 

%PROCESSDOC, "SU24”, ”G”, 1, 2, 0,0, 
l/*color*/, 40,40, 600,320; 

/* "Su-27 FLANKER” */ 

%CALL, "COMMON”, 2; 

@clearscreen = 1 ; 

%PROCESSDOC, "Flanker”, ”G”, 1, 2, 0,0, 
l/*color*/, 40,40, 600,320; 

/* "Yak-38 FORGER” */ 

%CALL, "COMMON”, 2; 

@clearscreen = 1 ; 

%PROCESSDOC, ”Forger_l”, ”G”, 1, 1, 0,0, 
l/*color*/, 40,40, 600,320; 

%CALL, "COMMON”, 3;/* Invalid Selection */ 
@clearscreen = 0 ; 


%DEFAULT: 


/* SELECTION NOT YET AVAILABLE */ 
%CALL, "GENERIC", 3; 
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§clearscreen = l; 

}/* end CHOICE */ 

%EXECUTE, "Fighters", 2 ; 

END OBJECT 


/* 3: Menu, SORTED BY NATO CODENAME */ 

%IF, §clearscreen =1; 

{ 

%CIiEARSCREEN , 10/*lt. green bkgnd*/; 

>/* "'• /* -use instructions ./ 

%FONT, "Systein24.fnt"; 

%WRITE, 20,470, 15/*white Itrs*/# 8/*dk.grev bkand*/ 

" MENU LEVEL: Mein -> unit --> Aclt --> lighters " 

"—> BY CODENAME "; i?ignters , 

%F0NT, "Systein72.fnt"; 

%MENU &choicevar, 210,100, 5/*default choice*/, 

" FIGHTER AIRCRAFT ", ' 

" - SORTED BY NATO CODENAME - " 

"[return to previous menu]", 

"[exit GEOTREC]", 


"FENCER (Su-24) ", ' 

"FITTER (Su- 20 / 22 )") 
"FLANKER (Su-27) , 

"FLOGGER (MiG-23) ", 
"FORGER (Yak-38) , 

"FOXBAT (MiG-25) ", 

"FOXHOUND (MiG-25)", 
"FROGFOOT (Sll-25) " 
"FULCRUM (MiG-29) ", 

%FUNCTIONKEY, "ESC", "Fightirs" 
%CHOICE, fitchoicevar; 


/ 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 


choice 2 */ 
choice 3 */ 
separator */ 
choice 5 */ 
choice 6 */ 
choice 7 */ 
choice 8 */ 
choice 9 */ 
choice 10 */ 
choice 11 */ 
choice 12 */ 
choice 13*/ 
separator */ 


{ 


%CASE= 2: 
%CASE= 3: 

%CASE= 4: 
%CASE= 5: 


%EXECUTE, 


/*"[Return to prev.menul"* 
"Fighters", i; ' 

/* "[Exit GEOTREC]" */ 


%CALL, "COMMON", 4; 

@clearscreen = 0 ; 

%CALL, "COMMON", 3;/. Invalid Selection */ 
@clearscreen = 0 ; 

.. /* "FENCER (Su-24)" */ 

%CALL, "COMMON", 2; \ J / 

@clearscreen = i; 

%PROCESSDOC, "SU24". "G" I P n n 
l/*color*/, 40,40, 600,320; 









%CASE= 7; /* "FLANKER (Su-27)'' */ 

%CALL, "COMMON”, 2; 

@clearscreen =1; 

%PROCESSDOC, "Flanker", ”G", 1,.2, 0,0, 
l/*COlor*/f 40,40, 600,320; 

%CASE= 9; /* "FORGER (Yak-38)" */ 

%CALL, "COMMON”, 2; 

§clearscreen = 1; 

%PROCESSDOC, "Forger_l", "G”, l, l, o,0, 
l/*color*// 70,140, 570,315; 

%CASE= 14; %CALL, "COMMON", 3;/* Invalid Selection */M 
@clearscreen =0; * 


%DEFAULT: /* SELECTION NOT YET AVAILABLE */ 

%CALL, "GENERIC”, 3; 

§clearscreen =1; 

}/* end CHOICE */ 

%EXECUTE, "Fighters”, 3; 

END OBJECT 


m 


J. HELOS.YOB 
/* 1: Helos */ 

%IF, @clearscreen = l; 

{ 

%C^ARSCREEN, 13/*lt.magenta bkgnd*/; 
eclearscreen = 0 ; ^ » 

}/* end IF */ 

%FONT, "System24.fnt"; 

" HELICOPTERS n. Aircraft -> »», 

%IF, @disdoc =1; 

{ 

%DISDOC, "Helix 1”, "G", 1 2 0 0 

0 , 0 , 640,480; ' ' ' 15/*black on bkgnd*/, 

@disdoc * 0; 

}/* end IF */ 

%CALL, "COMMON", 1; ^ 

%F0NT, ”System72.fnt"; ■ mouse instructions */ 

%MEiro, Ssortvar 50,50, l/*default choice*/, 
list aircraft names sorted BY: 

"DESIGNATOR ", 

"NATO CODENAME”. 

It--- 

"[return to previous menul”. 

"[exit GEOTREC]”; 

%CHOlCE, Ssortvar; 

%EXECUTE, "Helos", 2; 

%EXECUTE, "Helos”, 3; 

@clearscreen = i; 

%EXECUTE, "Aircraft”, i; 

%CALL, "COMMON”, 4; 

%CALL, "COMMON", 3; 


II 


/* choice 1 */ 
/* choice 2 */ 
/* separator */ 
/* choice 4 */ 
/* choice 5 */ 


%CASE* 1: 
%CASE= 2: 
%CASE= 4; 


%CASE= 5: 
%DEFAULT: 

}/* end CHOICE */ 
%EXECUTE, "Helos", 1; 
END_OBJECT 


SORTED BY DESIGNATOR */ 

^XF, @clea3rsc3reen = ij * 

{ 

^V*lt.magenta bkgnd*/; 

%CALL, "COMMON" 1• ^ 

}/* end IF */ ' ' ' mouse instructions */ 

%F0NT, "System24.fnt”; 
fS level:' 

%F0N?, " '* 

%MENU, Schoicevar, 210,100, 5/*default choice*/. 
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•• HELICOPTfiJiS •', 

'• - SORTED BY DESIGNATOR - , 

'•[return to previous menu]", 
"[exit GEOTREC]", 


"Ka-25 Hormone ", 

"Ka-27 Helix ", 

"Mi-8 Hip ", 

"Mi-14 Haze ", 

__"; 

%FUNCTIONKEY, "ESC", "Helos", 2; 

%CHOICE, Schoicevar; 

/* "[Return to prev.menu]" */ 
%EXECUTE, "Helos", 1; 

/* "[Exit GEOTREC]" */ 

% CALL, "COMMON", 4; 

@clearscreen = 0; 

%CALL, "COMMON", 3;/* Invalid Selection */ 
§clearscreen = 0; 

/* "Ka-25 Hormone" */ 

%CALL, "COMMON", 2; 

@clearscreen = 1; 

%PROCESSDOC, "VII_Hor2", "G", 1,1, 0,0, 
l/*COlor*/» 30,40, 610,290; 

/* "Ka-27 Helix" */ 

%CALL, "COMMON", 2; 

@clearscreen =1; 

%PROCESSDOC, "HelixBig", "G", 1, 1, 0,0, 
l/*COlor*/, 10,30, 630,440; 

%CALL, "COMMON", 3;/* Invalid Selection */ 
@clearscreen = 0; 

/* SELECTION NOT YET AVAILABLE */ 
%CALL, "GENERIC", 3; 

@clearscreen = 1; 

}/* end CHOICE */ 

%EXECUTE, "Helos", 2; 

END_OBJECT 

/* 3: Menu, SORTED BY NATO CODENAME */ 

%IF, @clearscreen = 1; 

^ %CLEARSCREEN, 13/*lt.magenta bkgnd*//' 

%CALL, "COMMON", 1; /* mouse instructions */ 

}/* end IF */ 


%CASE= 2: 

%CASE= 3: 

%CASE= 4: 

%CASE= 5: 

%CASE= 6; 

%CASE= 9: 

%DEFAULT: 


/* choice 2 */ 
/* choice 3 */ 
/* separator */ 
/* choice 5 */ 
/* choice 6 */ 
/* choice 7 */ 
/* choice 8 */ 
/* separator */ 


128 





%FONT, "Systein24. fnt"; 

" Helos ~> BY CODENAME "; ' 

%FONT, "System?2.fnt”; 

%MEHU, 5/.aefault choiceV, 

" “ SORTED BY NATO CODENAME - •' 

"rSit’GEOTREC?«^°“® menu]”, /* choice 2 ./ 
..i GEOTREC]", /* choice 3 */ 


"HAZE (Mi-14) •• ' 

"HELIX (Ka-27) », 

"HIP (Mi-8) It 

"HORMONE (Ka-25) 

—— ——— — — —If • 

%FUNCTIONKEY, "ESC", "Helos", 3; 
%CHOiCE, Schoicevar; 


/* choice 3 */ 
/* separator */ 
/* choice 5 */ 
/* choice 6 */ 
/* choice 7 */ 
/* choice 8 */ 
/* separator */ 


%CASE= 2: 


%CASE= 3: 


%EXECUTE, ”Helo^'”'lf"’'" V 


%CALL, "COMMON", 4; 
@clearscreen = 0 ; 


/* "[Exit GEOTRECJ" */ 


’ iSs:s°r6 , ^ =-i-tion V 

%CALL, ..COMMON”, 2f 
§clearscreen = 1 ; 

%PROCESSDOC, "HelixBig", "G" 11 n n 

l/*COlorV, lOVso; 630,440r ' ' 

%CASE= 8: /* ..T, 

' "Ka-25 Hormone" */ 

%CALL, "COMMON", 2; / 

@clearscreen = 1 ; 

%PROCESSDOC, "VII Hor2", "G" linn 
l/*color*/, 30,40, 610,290/ 

%CASE= 9: invalid Selection V 


%DEFAULT: 


)/* end CHOICE */ 
%EXECUTE, "Helos", 3; 

end_object 


%CALL, available */ 

@clearscreen = 1 ; 
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K. CARRIERS.YOB 
/* 1: Carriers */ 

%IF, §clearscreen = 1; 


/* set by UnitMenu object */ 


%CLEARSCREEN, ll/*lt. azure bkgnd*/? 
§clearscreen = 0; 


%F0NT. "SYstem24.fnt"; j*/ 

%WRITE, 20,470, 15/*white l^rS:*/' ®/*ircRAFT CRIERS", 

•' MAIN MENU: Main —> Unit —> AIRCRAFT CAKK1 £.k& , 

%ir, Misdoc = l; ' ' /* set by UnitMenu object */ 

‘ %DISDOC, "Tbilisil”, "G”, 0, 1, 0,0, 15/*black on bkgnd*/. 
75,50, 550,325; 

§disdoc = 0; 

%CALL?'^''C0MM0N'', 1; /* ^ouse instructions */ 

%F0NT, ''Systein72.fnt'’; 

%MENU, fisortvar, 250, 300, l/*default choice /, 

" LIST AIRCRAFT CARRIERS BY: ”, 

"TYPE (CV, CVHG, etc.)”/ 

'•CLASS NAME", 

--", 


"[return to previous menu]" 
"[exit GEOTREC]"; 

%CH0ICE, Stsortvar; 


/* choice 1 */ 
/* choice 2 */ 
/* separator */ 
/* choice 4 */ 
/* choice 5 */ 


%CASE= i; 

%EXECUTE, "Carriers", 

2; 

%CASE= 2: 

%EXECUTE, "Carriers", 

3; 

%CASE= 4: 

@clearscreen = 1; 



%EXECUTE, "UnitMenu", 

1; 

%CASE= 5: 

%CALL, "COMMON", 4; 



%EXECUTE, "Carriers", 

i; 

%DEFAULT: 

%CALL, "COMMON", 3; 



)/* end CHOICE */ 
%EXECUTE, "Carriers", 1; 
END OBJECT 


/* 2 : 
%IF, 

{ 


Menu, SORTED BY TYPE */ ^ ^ / 

iclearscreen = l;/*screen cleared except 1st time thru / 


%CLEARSCREEN, ll/*lt. azure bkgnd*//' . ^ 

%CALL, "COMMON", 1; /* mouse instructions 


*/ 


%FONT, "System24.fnt"; 

%WRITE, 20,470, 15/*white Itrs.*// 8/*dk.grey bkgnd /, 
" MENU LEVEL: Main —> Unit —> Carriers > , 

" SORTED BY TYPE " /* 

%F0NT, "System72.fnt"; 
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%MENU, fichoicevar, 225,100, 5/*default choice*/. 

" AIRCRAFT CARRIERS 
" - SORTED BY TYPE - ”, 

[exit GEOTREC]”, /* choice 3 */ 


"CHG (MOSKVA) ”, 

"CVHG (KIEV) ”, 

"CVxx (TBILISI) ”, 

”CVyy (ULYANOVSK)”, 

— — — — — — — — — — — — — — • 

%FUNCTIONKEY, ”ESC”, "Carriirs”, 2; 
%CHOICE, Sechoicevar; 


/* choice 3 */ 
/* separator */ 
/* choice 5 */ 
/* choice 6 */ 
/* choice 7 */ 
/* choice 8 */ 
/* separator */ 


%CASE= 2: 


%CASE= 3; 


%CASE= 5: 


%CASE= 6: 


„„„„ /*”[Return to prev.menul”*/ 

%EXECUTE, "Carriers”, i; ^ 


/* "[Exit GEOTREC]" */ 


%CASE= 7: 


%CASE= 8; 


%DEFAULT: 


%CALL, "COMMON”, 4; 
@clearscreen = O; 


.. /* "CHG (MOSKVA)” */ 

%CALL, "GENERIC”, 3; ' 

@clearscreen =1; 

.. /* "CVHG (KIEV)” */ 

%CALL, "COMMON”, 2; 

@clearscreen = l; 

%PROCESSDOC, "Baku”, ”G”, 1,1, -20,0, 
l/*COlor*/, 150,90, 515,390; 

/* "CVxx (TBILISI)” */ 
%CALL, "COMMON”, 2; ' 

/*so screen'll clear */ 
%PROCESSDOC, "Tbilisil”, ”G”, 1 1 0 0 

2/*blk on wt*/, 50,50, 550,325;' 

.. /* "CVyy (ULYANOVSK)" */ 

%CALL, "GENERIC", 3; ' ' 

@clearscreen = l; 

.. /* Invalid selection */ 

%CALL, "COMMON", 3; ' 

@clearscreen = O; 


}/* end CHOICE */ 

%EXECUTE, "Carriers”, 2; 

END_OBJECT 

/* 3: Menu, SORTED BY CLASS NAME */ 

%IF, @clearscreen = l;/*screen cleared except 1st time thru*/ 


%CLEARSCREEN, ll/*lt.azure bkgnd*/; 
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%CALL, "COMMON”, 1; 


/* mouse instructions */ 


} 


%FONT, "System24.fnt"; 

%WRITE, 20,470, 15/*white ltrs.*/f 8/*dk.grey bkgnd*// 
" MENU LEVEL: Main —> Unit —> Carriers —> ", 
"SORTED BY CLASS NAME "; 

%FONT, "System72.fnt"; 

%MENU, Schoicevar, 225,100, 5/*default choice*/, 

" AIRCRAFT CARRIERS ", 

" - SORTED BY CLASS NAME - ", 

"[return to previous menu]", 

"[exit GEOTREC]", 


"KIEV CVHG " 
"MOSKVA CHG " 
"TBILISI CVXX " 
"ULYANOVSK CVyy" 


%FUNCTIONKEY, "ESC", 
%CHOICE, &choicevar; 


I 

'•Carriers", 


/* choice 2 */ 
/* choice 3 */ 
/* separator */ 
/* choice 5 */ 
/* choice 6 */ 
/* choice 7 */ 
/* choice 8 */ 
/* separator */ 


{ 


%CASE= 2: 

%CASE= 3: 

%CASE= 5: 


%CASE= 6: 


%CASE= 7 


%CASE= 8; 


%DEFAULT: 


/* previous menu */ 
%EXECUTE, "Carriers", 1; 

/* "[Exit GEOTREC]" */ 

%CALL, "COMMON", 4; 

@clearscreen -= 0; 

/* "KIEV CVHG" */ 

%CALL, "COMMON", 2; 

@clearscreen = l; 

%PROCESSDOC, "Baku", "G", 1,1, -20,0, 
l/*COlor*/, 150,90, 515,390; 

/* "MOSKVA CHG" */ 
%CALL, "GENERIC", 3; 

@clearscreen =1; 

/* "TBILISI CVXX" */ 

%CALL, "COMMON", 2; 

@clearscreen = 1;/* so screen'll clear*/ 
%PROCESSDOC, "Tbilisil", "G", 1, 1, 0,0, 
2/*blk on Wt*/, 50,50, 550,325; 

/* "ULYANOVSK CVyy" */ 
%CALL, "GENERIC", 3; 

@clearscreen =1; 


%CALL, "COMMON", 3; 
@clearscreen = 0; 


/* Invalid selection */ 
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}/* end CHOICE */ 
%EXECUTE, "Carriers”, 3 ; 
END OBJECT 








L. 8URFC0MB.Y0B 
/* 1: SurfComb */ 

%IF, @clearscreen =1; 

{ 

%CLEARSCREEN, 15; 

@clearscreen =0; 

}/* end IF */ 

%FONT, ''System24. fnt”; 

%WRITE, 20,470, 15/*white Itrs.*// 8/*dk.grey bkgnd*/» 

” MENU LEVEL: Main —> Unit —> SURFACE COMBATANTS ", 

II II j 

%IF, @disdoc =1; 

^ %DISDOC, "Slava_2”r "G”, 0, 1, 0,-10, 15/*blk on bkgnd*/i 
30,20, 610,375; 

§disdoc =0; 

}/* end IF */ 

%FONT, "System96.fnt”; 

%DISTEXT, §menuwin, 355,60, 13/*black on It.magenta*// 

" SURFACE COMBATANTS ”; 

%FONT, ”System24.fnt”; 

%DISTEXT, @presswin, 105,215, ll/*black on It.azure*/, 

” Press number or first ”,, 

" capital letter of ",, 

” desired selection: ”; 

%FONT, ”System72.fnt”; 

%DISTEXTSTOP, Schoicevar, 108,261, ll/*black on It.azure*/, 

” 

” 1. Major”,, /* 1 = ASCII 49; M = ASCII 77 */ 

” 2. minor”,, /* 2 = ASCII 50; I = ASCII 73 */ 

” 3. Patrol craft”,, /* 3 = ASCII 51; P = ASCII 80 */ 

” 4. minesweepers”,, /* 4 = ASCII 52; S = ASCII 83 */ 

” 5. Amphibs/landing crft”,,/*5= ASCII 53; A = ASCII 65 */ 
” 6. Return to prev.menu”,,/*6 = ASCII 54; R = ASCII 82 */ 
” 7. Exit GEOTREC",, /* 7 = ASCII 55; E = ASCII 69 */ 

II •• . 

% CALL, ”COMMON”, 5; 

@callerobj = "SurfComb”; 

%CHOICE, Stchoicevar; 

^ /* ”6. Return to prev.menu”*/ 

%CASE= 54: /* ”6” in ASCII */ 

@clearscreen =1; 

%EXECUTE, "UnitMenu”, 1; 

%CASE= 82: /* ”R” in ASCII */ 

@clearscreen =1; 

%EXECUTE, "UnitMenu”, 1; 

/* ”7. Exit GEOTREC" */ 

%CASE= 55: /* ”7” in ASCII */ 
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%CASE= 69: 


%CALL, "COMMON"> 4; 

/* "E" 

%CALL, "COMMON", 4; 


in ASCII */ 


%DEFAULT: 

%CALL, 

%CALL, 

}/* end CHOICE */ 
%EXECUTE, "SurfComb", 1 
END OBJECT 


available*/ 

"COMMON", 6; ' 

"GENERIC", 1; 
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M. TARANTUL.YOB 

/* 1: TARANTUL (if uSef clicks 6h HULL) */ 

@returnobj = "TARANTUL”; 

@returnnum =8; 

%FUNCTIONKEY, "ESC", @returnob3, @returnnuiti; 

%FONT, "Systeni24. fnt"; 

%PROCESSDOC, "TARANTUL", "T", 1,1, 0,0, 

ll/*black on It.azure*/f 35,365, 605,450; 

END_OBJECT 

/* 2: if user clicks on BANDSTAND radar */ 

%FONT, "Systein24.fnt"; ^ 

%DISTEXT, Sttextwin, 300,100, 10/*black on It.green /, 

" This is the BANDSTAND radar. "; 

%WAIT 1.0; 

%DISTEXTSTOP, &key, 125,445, 14/*black on yellow*/, 

" (Press M for More info on your selection, ,, 

" any other key to make another selection) "; 
%CLOSEWIN, Sitextwin; 

/* "M" in ASCII */ 

%CALL, "GENERIC", 3; 

%EXECUTE, "TARANTUL", 8; 

%EXECUTE, "TARANTUL", 7; 

}/* end CHOICE */ 

END_OBJECT 

/* 3: if user clicks on SS-N-22 launchers */ 

%FONT, "System24.fnt"; 

%DISTEXT, Sttextwin, 225,300, 10/*black on It.green*/, 

" This is an SS-N-22 launcher. "; 

%WAIT,,1.0; , n-, */ 

%DISTEXTSTOP, Stkey, 125,445, 14/*black on yellow*/, 

" (Press M for More info on your selection, ",, 

" any other key to make another selection) "; 
%CL0SEWIN, Stextwin; 

%CH0ICE, Stkey; 

^ %CASE= 77: /* *'”” ASCII */ 

%FUNCTIONKEY, "ESC", "TARANTUL", 8; 
%EXECUTE, "TARANTUL", 9; 

%DEFAULT: %EXECUTE, "TARANTUL", 7; 

}/* end CHOICE */ 

END_OBJECT 

/* 4: if user clicks on 76mm gun */ 

%FONT, "System24.fnt"; 

%DISTEXT, Sttextwin, 400,150, 10/*black on It.green*/, 

" This is a 76mm dual-purpose naval gun. "; 


%CHOICE, &key; 

{ 

%CASE= 77; 


%DEFAULT: 
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%WAIT,,1.0; 

%DISTEXTSTOP, &key, 125,445, 14/*black on yellow*/, 
" (Press M for More info on your selection, 

” any other key to make another selection) 
%CLOSEWIN, fitextwin; 

%CHOICE, &key; 


%CASE= 77: 


%DEFAULT: 

)/* end CHOICE */ 
END OBJECT 


/* "M" in ASCII */ 
%FUNCTIONKEY, "ESC", "TARANTUL”, 8; 
%EXECUTE, "TARANTUL", 10; 

%EXECUTE, "TARANTUL", 7; 


/* 5: if user clicks on BASS TILT radar */ 

%F0NT, "System24.fnt»'; 

%DISTEXT, fitextwin, 225,100, 10/*black on It. green*/, 
" This is the BASS TILT radar. 

%WAIT,,1.0; 

%DISTEXTSTOP, &key, 125,445, 14/*black on yellow*/, 

'• (Press M for More info on your selection, ",, 

" any other key to make another selection) 
%CL0SEWIN, fitextwin; 

%CH0ICE, &key; 


%CASE= 77 


%DEFAULT: 

}/* end CHOICE */ 
END object 


/* "M" in ASCII */ 

%CALL, ''GENERIC", 3; 

%EXECUTE, "TARANTUL", 8; 

%EXECUTE, "TARANTUL", 7; 


/* 6: if user clicks on ADMG-630 */ 

%F0NT, "System24.fnt"; 

%DISTEXT, Stextwin, 30,150, 10/*black on It.green*/, 
" This is an ADMG-630 catling gun. 

%WAIT,,1.0; 

%DISTEXTSTOP, &key, 125,445, 14/*black on yellow*/, 

" (Press M for More info on your selection, 

" any other key to make another selection) 
%CLOSEWIN, Stextwin; 

%CHOICE, &key; 


%CASE= 77 


%DEFAULT; 

)/* end CHOICE */ 
END OBJECT 


/* "M" in ASCII */ 
@returnobj = "TARANTUL"; 

§returnnum = 8; 

%EXECUTE, "TARANTUL", 11; 

%EXECUTE, "TARANTUL", 7; 


137 




/* 7: to re-PROCESSDOG(”G'') Tarantul w/out redraw */ 
%FUNCTIONKEY, ''ESC, ©callerobj, ecallernuin; 
%PROCESSDOC, "TARANTUL”, "G"; 

END OBJECT 


/* 8: if user ESCs from PROCESSDOC("T") */ 
%FUNCTIONKEY, "ESC", @callerobj, @callernum; 

%CALL, "COMMON", 2; ^ / 

%PROCESSDOC, "TARANTUL", "G", 1,1, 0,0, l/*COlor /, 
20,25, 620,455; 

END OBJECT 


/* 9: call PROCESSDOCC'T") SS-N-22 */ ^ * 

/* This is broken out from "TARANTUL", 3 * 

* so that it can also be called by a user * 

* 'click* from PROCESSDOC, "TARANTUL", "G"* 


*/ 

%EXECUTE, "SSN22", 1; 
END OBJECT 


/* 10: call PROCESSDOCC'T") 76mm*/ 
%CALL, "GENERIC", 3; 

%EXECUTE, "TARANTUL", 8; 

END_OBJECT 


/ 


* 11: call PROCESSDOC ADMG-630 */ 

/* This is broken out from "TARANTUL", 6 

* so that it can also be called by a user 

* 'click' from PROCESSDOC, "TARANTUL", "G" 


* 

* 

* 


*/ 

%EXECUTE, "ADMG630", 1; 
END OBJECT 
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N. SUBS.YOB 

/* 1: Siibs */ 

%IF, §clearscreen = 1; 

{ 

%CLEARSCREEN, 9/*lt.blue bkgnd*/; 

@clearscreen = 0; 

}/* end IF V 

%FONT, "System24. fnt'•; 

%WRITE, 20,470, 15/*white ltrs.*/f 8/*dk.grey bkgnd*/, 

" MENU LEVEL: Main —> Unit —> SUBMARINES ”, 

%IF, @disdoc =1; 

{ 

%DISDOC, ”VII_Hor2”, ”G”, 0, 1 , 0,0, 0/*bkgnd on white*/, 
10,10, 630,250; " 

@disdoc = 0; 

}/* end IF */ 

% FONT, "Systems 6.fnt”; 

%DISTEXT, @menuwin, 200,75, 5/*white on red*/, 

'' SUBMARINES ”; 

%FONT, ”System24.fnt”; 

%DISTEXT, @presswin, 200,235,.l5/*black on white*/, 

” Press number or first ",, 

” capital letter of ”,, 

" desired selection; 

%FONT, "System72.fnt"; 

%DISTEXTSTOP, &choicevar, 205,281, 15/*black on white*/, 

" 1. Attack (SSN/SS)",, /* 1 = ASCII 49; A = ASCII 65 */ 

2. Boomers (SSBN/SSB)",,/* 2 = ASCII 50; B = ASCII 66 */ 

3. Shooters (SSGN/SSG) ",,/*3= ASCII 51; S = ASCII 83 */ 

4. Other submarines",, /* 4 = ASCII 52; 0 = ASCII 79 */ 

5. Return to prev.menu",,/*5 = ASCII 53; R = ASCII 82 */ 

6. Exit GEOTREC",, /* 6 = ASCII 54; E = ASCII 69 */ 

%CALL, "COMMON", 5; 

§callerobj = "Subs"; 

%CH0ICE, &choicevar; 


%CASE= 


%CASE= 82 


/* "5. Return to prev.menu"*/ 
/* "5" in ASCII */ 

§clearscreen =1; 

%EXECUTE, "UnitMenu", l; 

/* "R" in ASCII */ 

@clearscreen = l; 

%EXECUTE, "UnitMenu", l; 


<1.0*... /* GEOTREC" */ 

%CASE- 54: /* iigH in ASCII */ 

%CALL, "COMMON", 4; 

%CASE= 69: /* iiEn in ASCII */ 
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%CALL, “COMMON’', 4; 


%DEFAULT; /* selection not yet available*/ 

%CALL, “COMMON”, 6; 

%EXECUTE, “GENERIC", 1; 

}/* end CHOICE */ 

%EXECUTE, “Subs", 1; 

END OBJECT 
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O. AUZILS.YOB 

/* 1: Auxils */ 

%IF, §clearscreen = l; 

{ 

%CLEARSGREEN, 7/*lt.grey bkgnd*/; 

@clearscreen = 0 ; 

}/* end IF V 
%FONT, "System24.fnt''; 

%WRITE, 20,470, 15/*white Itrs.*// 8/*dk.grev bkand*/ 

- MENU level: Main -> unit -i ATOSLlil "/' 

%IF, @disdoc =1; 

{ 

*“8“w,’'53o!IIo"' lV*black on bkgnd*/, 

@disdoc = 0; 

}/* end IF */ 

%FONT, '• Systems6.fnt"; 

%DISTEXT, @menuwin, 200,125, 14/*black on yellow*/, 

'• AUXILIARIES jr x w /, 

% FONT, " Sy S t em2 4. f n t ; 

%DISTEXT, Ipresswin, 200,235, 13/*black on It.magenta*/. 
Press number or first »•,, 

" capital letter of ••,, 

" desired selection: 

%FONT, ''System72.fnt”; 

%DlSTEXTSTOP, fichoicevar, 205,281, 13/*black on It.magenta*/, 

« I' AGIs/research",, /V i = ASCII 49; a =» ASCII 65 */ 

II service",, /* 2 = ASCII 50; F = ASCII 70 */ 

" I' ShSS /* 3 = ASCII 51; S = ASCII 83 */ 

H t' auxiliaries",, /* 4 = ASCII 52; O = ASCII 79 */ 

5. Return to prev.menu",,/*5 = ASCII 53; R = ASCII 82 */ 
;; 6. Exit GEOTREC",, /i g = ASCII 54,: E = AScll 69 */ 

%CALL, "COMMON", 5; 

@callerobj = "Auxils"; 

%CHOICE, fichoicevar; 


{ 


%CASE= 53: 
%CASE= 82: 

%CASE= 54: 
%CASE= 69: 


/* "5. Return to prev.menu" */ 

- , /* "5" in ASCII */ 

@clearscreen = 1 ; 

%EXECUTE, "UnitMenu", i; 

^ , /* "R" in ASCII */ 

eclearscreen = 1 ; 

%EXECUTE, "UnitMenu", i; 


%CALL, "COMMON", 4; 


/* "6. Exit GEOTREC" */ 
/* "6" in ASCII */ 

/* "E" in ASCII */ 
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%CALL, "COMMON", 4; 


%DEFAULT; /* selection not yet 

%CALL, "COMMON", 6; 

%EXECUTE, "GENERIC", 1; 

}/* end CHOICE */ 

%EXECUTE, "Auxils", 1; 

END OBJECT 


available*/ 
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P. NERSHIPS.YOB 
/* 1: Merships */ 

%IF, @clearscreen =1; 

{ 

%CLEARSCREEN, 12/*lt.red bkgnd*/; 

@clearscreen = 0; 

>/* end IF */ 

%FONT, '•System24.fnt"; 

%WRITE, 20,470, i5/*white Itrs.*/, 8/*dk.grey bkgnd*/, 

MENU LEVEL: Main —> Unit —> MERCHANT SHIPS ”, 

%IF, idisdoc = 1; 

{ 

§disdoc =0; 

}/* end IF */ 

%FONT, "Systein96. fnt" ; 

%DISTpT, imenuwin, 203,125, 0/*white on black*/. 

” MERCHANT SHIPS ”; 

%F0NT, ”Systeni24.fnt"; 

%DISTpT, epresswin, 200,180, 9/*black on It.blue*/. 

Press number or first ”,, 

" capital letter of ”,, 

” desired selection: 

%FONT, ”System72.fnt”; 

%DISTEXTSTOP, Schoicevar, 203,226, 9/*black on It.blue*/, 

•" i’ il!" /*'l => ASCII 49 */ 

II /* 2 = ASCII 50 */ 

II ^^^® ^ " /* 3 « ASCII 51 */ 

II K* /Sf®- . /* 4 = ASCII 52 */ 

5. Other merships",, /* 5 = ASCII 53; 0 = ASCII 79*/ 

II t' prev.menu", ,/*6 = ASCII 54; R = ASCII 82*/ 

” 7. Rvit- dPnfTDwr'ii ___ _ o^. / 


” 7. Exit GEOTREC",, 

II 

%CALL, "COMMON", 5; 
@callerobj = "Merships"; 
%CHOICE, Schoicevar; 


/* 7 - ASCII 55; E = ASCII 69*/ 


%CASE= 54: 
%CASE= 82: 

%CASE= 55: 
%CASE= 69: 


/* 

@clearscreen = l; 

II 6 H 

in ASCII 

V 

%EXECUTE, "UnitMenu", 

1; 



/* 

@clearscreen = l; 

"R" 

in ASCII 

*/ 

%EXECUTE, "UnitMenu", 

1; 



/* 

"7. 

Exit GEOTREC" 

/* 

%CALL, "COMMON", 4; 

lly II 

in ASCII 

*/ 

/* 

"E" 

in ASCII 

*/ 


143 







%DEFAULT; 


%CALL, "COMMON”, 4; 

/* selection not yet available */ 
%CALL, "COMMON", 6; 

%EXECUTE, "GENERIC", 1,* 

}/* end CHOICE */ 

%EXECUTE, "Merships", 1; 

END OBJECT 
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Q. WEAPMENU.YOB 

/* 1: WeapMenu */ 

%IF, @clearscreen = l; 

{ 

%CLEARSCREEN,- 3/*a2ure bkgnd*/; 

@clearscreen = 0 ; 

)/* end IF */ 

%FONT, "System24.fnt"; 

%WRITE,^0,470, 15/*white Itrs.*// 8/*dk.grey bkgnd*/, 
MENU LEVEL: Main —> WEAPONS ” U // 


If 


%IF, 

{ 


§disdoc = 1; 


N 


%DISWC,o«ADMG630», "G", 1 , 1 , 0,-10, 15/.blk on bkgV, 

@disdoc =0; 

)/* end IF */ 

%FONT, ''Systein96. fnt”; 

%DISTEXT, @titlewin, 355,40, 8/*white on dk.grey*/ 

WEAPONS MENU ; 9 7/, 

%FONT, "System24.fnt”; 

%DISTEXT, epresswin, 106,205, 7/*black on It.grey*/ 

Press number or first ”,, ■a j' /v 

” capital letter of 

" desired selection: 

"?Ystejn72.fnt”; 

105,251, 


%DISTEXTST0p, Schoicevar, 


" 1. Missiles",, 

” 2. Naval guns”,. 


II 


7/*black on It.grey*/. 


3. SLBMs”,, 

4. Torpedoes”,, 

5 . Other weapons”,, 


/* 1 = ASCII 49; M = ASCII 77 */ 

/* 2 = ASCII 50; N = ASCII 78 */ 

/* 3 = ASCII 51; - 

/* 4 = ASCII 52; 

/* 5 = ASCII 53; 


' ASCII 54 ; « = ASCII 82 V 
7. Exit GEOTREC",, /* 7 = ASCII 55; E = ASCII 69 ♦/ 


S = ASCII 83 */ 
T = ASCII 84 */ 
O = ASCII 79 */ 
R = ASCII 82 */ 


% CALL, ”COMMON”, 5; 
@callerobj = "WeapMenu” 
%CHOICE, Schoicevar; 

{ 


/* close window;^ */ 
GENERIC knows Ob j that called*/ 


/’ 


%CASE= 49: 


%CASE= 77: 


/* ”1. Missiles” */ 

- /* "1” in ASCII */ 

%CALL, "COMMON”, 6; ^ 

%EXECUTE, "GENERIC”, 1; 

%EXECUTE, "Missiles”, 1 ;*/ 

.. /* ”M” in ASCII */ 

%CALL, "COMMON”, 6; 

%EXECUTE, "GENERIC", 1; 
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%EXECUTE, "Missiles", 1;*/ 

/* "2. Naval guns" */ 

/* "2" in ASCII */ 

%CALL, "COMMON", 6; 

%EXECUTE, "GENERIC", 1; 

%EXECUTE, "NavGuns", 1;*/ 

/* "N" in ASCII V 

%CALL, "COMMON", 6; 

%EXECUTE, "GENERIC", 1; 

%EXECUTE, "NavGuns", 1;*/ 

/* "3. SLBMs" */ 

/* ''3" in ASCII */ 

%CALL, "COMMON", 6; 

%EXECUTE, "GENERIC", 1; 

%EXECUTE, "SLBMs", 1;*/ 

/* "S" in ASCII */ 

%CALL, "COMMON", 6; 

%EXECUTE, "GENERIC", 1; 

%EXECUTE, "SLBMs", 1;*/ 

/* "4. Torpedos" */ 

/* "4" in ASCII V 

%CALL, "COMMON", 6; 

%EXECUTE, "GENERIC", 1; 

%EXECUTE, "Torpedos", 1;*/ 

/* "T" in ASCII */ 

%CALL, "COMMON", 6; 

%EXECUTE, "GENERIC", 1; 

%EXECUTE, "Torpedos", 1;*/ 

/* "5. Other weapons" */ 
/* "5" in ASCII V 

%CALL, "COMMON", 6; 

%EXECUTE, "GENERIC", 1; 

%EXECUTE, "OthrWeap", 1;*/ 

/* "O" in ASCII */ 

%CALL, "COMMON", 6; 

%EXECUTE, "GENERIC", 1; 

%EXECUTE, "OthrWeap", 1;*/ 

/*"6.Return to prev.menu"*/ 


/* 

II6 « 

in 

ASCII 

*/ 

@clearscreen = 1; 
%EXECUTE, "MainMenu", 

1; 




/* 

"Rll 

in 

ASCII 

*/ 

@clearscreen = 1; 
%EXECUTE, "MainMenu", 

1; 





/* "7. Exit GEOTREC" */ 
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%CASE= 55: 


/* "7*' in ASCII V 

%CALL, "COMMON", 4; 

%CASE= 69: /* mem ASCII */ 

%CALL, "COMMON", 4; 

%DEFAULT: /* Invalid selection 

%CALL, "COMMON", 3; 

}/* end CHOICE */ 

%EXECUTE, "WeapMenu", l; 

END OBJECT 








R. ADMG630.yOB 
/* 1: ADMG-630 */ 

%OPENWIN, @winvar, 125,145, 425,390, 5/*magenta bkgnd*/ 
%FONT, ''System24.fnt''; 

%WRITE, 134,370, l5/*white Itrs*// 5/*inagenta bkgnd*/, 

•' ADMG-630 (air defense machine ",, 

'» gun with six Mom barrels) 

%FUNCTIONKEY, "ESC, "ADMG630", 2 ; 

%FONT, "System24.fnt"; 

%PROCESSDOC, "ADMG630", "G", 1,1, 0,-10, 
l/*COlor*/, 130,150, 420,355; 

END_OBJECT 

/* 2: ESC */ 

%CLOSEWIN, @winvar; 

%EXECUTE, ereturnobj, §returnnum; 

END OBJECT 


S. SSM22.yOB 
/* 1; SS-N-22 */ 

%FONT, "System24.fnt"; 

%PROCESSDOC, "SSN22", "T", 1,1, 0,0, 
13/*black on It.magenta*/, 
80,380, 560,450; 

END OBJECT 


T. QUIZZER.YOB 

/* 1: Welcome to Quizzer */ 

@usedonebefore = o; /* used in "Quizzer'' 2 */ 

§usedtwobefore = 0 ; /* « m h n 

%CLEARSCR£EN, ll/*lt.azure bkgnd*/; 

%FONT, "System96.fnt"; 

%DISTEXT, @titlewin, 114,100, l/*white on blue*/# 

" WELCOME TO THE RECOGNITION QUIZZER !1! "; 

%FONT, "System?2.fnt"; 

%DISTEXT, epresswin, 145,170, 9/*white on It.blue*/ 

" The Quizzer will randomly display threat ",, 

" units, weapons systems or sensors — your "' 

" task is to identify the image you see. '' 

%FONT, "System72.fnt"; 

%DISTEXTSTOP, Schoicevar, 223,255, 9/*white on It.blue*/, 
” PLEASE PRESS: ' 


'I 


" - S to Start quizzer 
" - R to Return to 
“ Main Menu 

" - E to Exit GEOTREC 

It 

%CALL, "COMMON", 5; 
§callerobj = "Quizzer"; 
§callernum = l; 

%CH0ICE, Schoicevar; 

{ ^ , 


/* S = ASCII 83 */ 
/* R = ASCII 82 */ 

/* E - ASCII 69 */ 

/* close windows */ 


%CASE=* 83: 


%CASE= 82 


%CASE= 69: %CALL, 
%DEFAULT: %CALL, 

}/* end CHOICE */ 
%EXECUTE, "Quizzer", 1; 
END OBJECT 


/* "S" in ASCII */ 

/* only initialize image variables if * 

* Quizzer menu called by Main Menu * 

*/:;■ ^ 

%IF, iquizcalledbymain = 1; 

%CALL, "Quizzer", 5;/*init'lize var.s*/ 
@quizcalledbymain = 0; 

}/* end IF */ 

%EXECUTE, "Quizzer", 2;/* start Quizzer */ 
%CALL|"COMMON'r, 6; 

%EXECUTE, "MainMenu", i; i 

%CALL, "COMMON", 4; 

%CALL, "COMMON", 3; 


Ipj 

— 

'SM:- 


/* 2: Start Quizzer */ 

%CLEARSCREEN, ll/*lt.azure bkgnd*/; 

/* RND(O) returns a whole number * 

* btwn 1 — 32767; modulo divides* 

* that set into blocks — the * 
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* number of blocks must be >= * 

* the number of §imageXXnames. * 
*/ 

&modulo = 2048;/*to divide set of random no.into 16 blocks*/ 
@rndvar = R0XJND(RND(0)/&modulo); 

/* To ensure the same image is 

* not used twice in a row. 

*/ 

%IF, @rndvar = @usedonebefore; 


* 

* 


{ 

%EXECUTE, "Quizzer", 2; 

}/* end IF */ 

/* To ensure same image is not * 
* repeated within two attempts. * 

*/ 

%IF, @rndvar = §usedtwobefore; 

{ 

%EXECUTE, "Quizzer", 2; 

}/* end IF */ 

gusedtwobefore = @usedonebefore; 

@usedonebefore = @rndvar; 

%CHOICE, @rndvar; 


{ 


%CASE= 1: 

%CASE= 2: 

%CASE= 3: 

%CASE= 4: 

%CASE= 5: 

%CASE= 6; 

%CASE= 7: 

%CASE= 8: 

%CASE= 9: 

%CASE=10: 


@name = @01name; ©image = ©Olimage; ©X = ©OIX; 

©Y = ©OlY; ©Xmin = ©OlXmin; ©Ymin = ©OlYmin; 

©Xmax = ©OlXmax; ©Ymax = ©OlYmax; 

©name = ©02name; ©image = ©02image; ©X = ©02X; 

©Y = ©02Y; ©Xmin = ©02Xmin; ©Ymin = ©02Ymin; 

©Xmax = ©02Xmax; ©Ymax = ©02Ymax; 

©name = ©03name; ©image = ©03image; ©X = ©03X; 

©Y = ©03Y; ©Xmin = ©03Xmin; ©Ymin = ©03Ymin; 

©Xmax = ©03Xmax; ©Ymax = ©03Ymax; 

©name = ©04name; ©image = ©04image; ©X = ©04X; 

©Y = ©04Y; ©Xmin = ©04Xmin; ©Ymin = ©04Ymin; 

©Xmax = ©04Xmax; ©Ymax = ©04Ymax; 

©name = ©OSname; ©image = ©OSimage; ©X = ©05X; 

@Y = ©05Y; ©Xmin = ©05Xmin; ©Ymin = ©OSYmin; 

©Xmax = ©OSXmax; ©Ymax = ©OSYmax; 

©name = ©06name; ©image = ©06image; ©X = ©06X; 

©Y = ©06Y; ©Xmin = ©06Xmin; ©Ymin = ©06Ymin; 

©Xmax = ©oexmax; ©Ymax = ©06Ymax; 

©name = ©07name; ©image = ©07image; ©X = ©07X; 

©Y = ©07Y; ©Xmin = ©07Xmin; ©Ymin = ©07Ymin; 

©Xmax = ©07Xmax; ©Ymax = ©07Ymax; 

©name = ©OSname; ©image = ©OSimage; ©X = ©08X; 

©Y = ©08Y; ©Xmin = ©OSXmin; ©Ymin = ©OSYmin; 

©Xmax = ©OSXmax; ©Ymax = ©OSYmax; 

©name = ©09name; ©image = ©09image; ©X = ©09X; 

©Y = ©09Y; ©Xmin = ©09Xmin; ©Ymin = ©09Ymin; 

©Xmax = ©09Xmax; ©Ymax = ©09Ymax; 

©name = ©lOname; ©image = ©lOimage; ©X = ©lOX; 
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eYmin - glOYmin; 

i/'ioi.-,, O S®"®* ■ eiOXmax; gYinax = eiOYmax; 

%CASE-ll; §name = @llname; eimage = §llimage; §x = eiix* 

@Y §11Y; §Xinin = §llXmin; §Yinin = §llYinin; 
arraQi?-io a @Xmax = eilXmax; §Ymax = §llYmax; 

%CASE-12: gnaiiie = §12name; gimage = §12image; §x = ei2X* 

«"in - 

arracTP-i-, A - eiZXmax; gYmax = §12Ymax; 

%CASE-13: @name = §13name; iimage = §13iinage; @x = ei 3 X* 

!tn^cv‘-^A A “ ei3Xmax; iYmax = §13Ymax; 

%CASE-14: ename = @14naine; § image * §14image; §x = ei4X* 

* §14Xmin; §Ymin = §l4Ymin; 
straQTT-iK A “ ei4Xmax; §Ymax = il4Ymax; 

%CASE-15. @name = @l5name; @image = §15image; gx = iisx* 

= eisaain; gY^in = 

iraciT-ig: A = §15Xmax; @Ymax = glSYmax; 

%CASE-16. gname - gl6name; gimage = gieimage; gx = gl6X; 

- @ 16 Ymin; 

gXmax — gl6Xmax; gYmax = gieYmax* 

}/* eSfSoiCE -Quizzer-, 2 ;/*get another rndvar*/ 

%DISDOC, gimage, »G», i,i, gx,gY, l/*color*/g 
gXmin,gYmin, gXmax, gYmax; 

%EXECUTE, "Quizzer", 3; 

END OBJECT 


/* 3: Quiz Answer */ 

%CALE, "COMMON'^ 1; 

Swronganswer = O; 

&whilevar « 1 ; 

%WHILE, &whilevar =1; 

%FONT, '•System72.fnt'‘; 

%MENU, ganswername, 450,50, 
" POSSIBLE CHOICES: '•, 
gOSname, 

§04name, 

@03name, 

glSname, 

@07name, 

@06name, 

§12name, 

@14name, 

g02name, 

§01name, 

@13name, 

@09name, 

gllname, 

@15naine, 

@10naine. 


/* mouse instructions */ 

/* "infinite” loop */ 

l/*default choice*// 

/*in alphabetical order*/ 
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eoSname, 

--.t, 

"Quit the Quizzer”; 

%IF, @answername = "Quit the Quizzer”; 

%EXECUTE, "Quizzer", 1; 

}/* end IF */ 

%IF, eanswername = §name; 

^ %FONT, "Systeia72.fnt"; 

%DISTEXTSTOP, fianykey, 180,350, 

9 /*white on It.blue*/, 

" CORRECT ANSWER — NICELY DONE!! ",, 

" (Press Q to Quit the Quizzer, ",, 

" M for More info on this image, ",, 

" or any other key to try again) "; 

%CHOICE, fianykey; 

^ %CASE= 77: /* "M" in ASCII */ 

%EXECUTE, "Quizzer", 4; 

%CASE= 81: /* "Q" in ASCII */ 

%EXECUTE, "Quizzer", 1; 

%DEFAULT: %EXECUTE, "Quizzer", 2; 

}/* end CHOICE */ 

}/* end IF */ 

%ELSE; 

^ %F0NT, "System72.fnt"; 

%DISTEXT, &textwin, 143,325, 14/*black on yellow*/ 

tl / 

" BZZZZZZT — WRONG-0, FERTILIZER BREATH !il ", 

tf 

Swronganswer = &wronganswer + l; 

%IF, &wronganswer <3; 

%DISTEXT, Swronganswin, 178,400, 

14/*blk on yel*/, 

" That was attempt #",Swronganswer, 

"; try again... "; 

%WAIT,,3.0; 

%CLOSEWIN, fietextwin; 

%CLOSEWIN, Swronganswin; 

}/* end IF */ 

%ELSE; /* if Swronganswer = 3 */ 

^ %DISTEXT, Sewronganswin, 153,400, 

14/*blk on yel*/, 

" THAT WAS YOUR THIRD AND LAST ATTEMPT !! " 

%WAIT,,2.0; 

%CLOSEWIN, fictextwin; 

%CLOSEWIN, Sewronganswin; 
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It 


%DISTEXTSTOP, fianykey, 130,350, 

13/*black on It.magenta*// 

THE CORRECT ANSWER WAS: ••,, 

-> ", @name," <-•— 

(Press Q to Quit the Quizzer, 

M for More info on this image, ”,, 

or any other key to try again) 

%CH0ICE, Sanykey; 

{ 

%CASE= 77: /* "M" in ASCII */ 

%EXECUTE, "Quizzer”, 4; 

%CASE= 81: /* ”Q” in ASCII */ 

%EXECUTE, "Quizzer”, 1; 
%DEFAULT: %EXECUTE, "Quizzer”, 2; 

}/* end CHOICE */ 

)/* end ELSE */ 

}/* end ELSE */ 

}/* end WHILE */ 

END_OBJECT 

/* 4: Processdoc for more info */ 

%CALL, "COMMON”, 6; 

%CALL, "COMMON”, 2; 

%FUNCTIONKEY, "ESC”, "Quizzer”, 2; 

%PROCESSDOC, @image, ”G”, 1,1, @X,@Y, 

l/*color*/, exmin,@Ymin, @Xmax, @Ymax; 

END_OBJECT 

/* 5: Initialize variables */ 

%F0NT, "System24.fnt”; 

%DISTEXT, fiinitwin, 245,240, 15/*black on white*// 

" INITIALIZING... 
eolname = ”Su-24 FENCER ”; 

@01image = "SU24”; 

@01X = 0; §01Y = 0; 

@01Xmin = 20; §01Ymin = 25; 

eOlXmax = 620; §01Ymax = 455; 

@02name = "SOVREMENNYY DDG ”; 

@02image = "SOVREM_2”; 

e02X = 0; @02Y = 0; * 

@02Xmin = 20; @02Ymin = 25; 

@02Xmax = 620; @02Ymax = 455; 

@03name = "KIEV CVHG Baku ”; 

@03image = "BAKU”; 

@03X = -15; @03Y = 0; 

@03Xmin = 150; @03Ymin = 90; 

@03Xmax = 515; @03Ymax = 390; 

@04name = "IVAN ROGOV LPD "; 

@04image = "IROGOV_l"; 

@04X = 0; @04Y = 0; 

@04Xmin = 20; @04Ymin = 25; 
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@04Xinax = 620; @04ymax - 
eosname = "YANKEE Notch SSGN ' 
§ 05 image = "YNOTCH_l"; 
§05X == 0; §05Y = 

§05Xmin = 20; 0O5Ymin - 

§05Xmax = 620; §05Ymax = 
§06name = "Mi-28 HAVOC 
§06image = "MI28"; 

§06X = 0; §06Y = 

§06Xmin = 20 ; §06Ymin - 

§06Xmax = 620; §06Ymax = 
§07name = "Mi-24 HIND 

§07image = "MI24"; 

§07X = 0; §07Y - 

§07Xmin = 20; §07Ymin = 

0O7Xmax = 620; 0O7Ymax = 
0O8name = "BALZAAM AGI 

§ 08 image = "BALZAAM"; 

0O8X = 0; 0O8Y = 

0O8Xmin = 85; 0O8Ymin = 

0O8Xroax = 530; 0O8Ymax = 
0O9name = "TARANTUL III PGG ' 
009image = "TARANTUL"; 
0O9X - -10; 0O9Y = 

§09Xmin = 20; 0O9Ymin = 

0O9Xmax = 620; 0O9Ymax = 
@10name = "Yak-38 FORGER ' 

@10image = "FORGER_l"; 
@10X = 0; @10Y = 

@10Xmin = 50; @10Ymin = 

@10Xmax = 590; @10Ymax = 
@llname = "TBILISI CV Tbilisi 
@llimage = "TBILISIl"; 
@11X = 0; @11Y = 

@llXmin = 50; @llYmin = 

@llXmax = 550; @llYmax = 
@12name = "OSCAR SSGN 

@12image = "OSCAR_2"; 
@12X = 0; @12Y = 

@12Xmin = 30; @12Ymin = 

@12Xmax = 610; @12Ymax = 
@13name = "Su-27 FLANKER B ' 
@13image = "FLANKER"; 
@13X = 0; @13Y = 

@13Xmin = 40; @13Ymin = 

@13Xmax = 600; @13Ymax = 
@14name = "SLAVA CG 

@14image = "SSN12"; 

@14X = 0; @14Y = 

@14Xmin = 20; @14Ymin = 

@14Xmax = 620; @14Ymax = 


455; 


0 ; 

25; 

455; 


0 ; 

25; 

455; 


0 ; 

25; 

455; 


0 ; 

50; 

300; 


o; 

25; 
455; 


0 ; 

30; 

330; 


0 ; 

50; 

325; 

tl • 

9 

0 ; 

50; 

430; 


0 ; 

40; 

320; 


0 ; 

25; 

455; 
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§15name * "Tu-ieo BLACKJACK 


eiSimage = "BLACKJ_1'’; 

@15X = 0; ilSY = 0 

§15Xmin = 20; eiSYmin = 25 

eiSXmax = 620; @15Yinax = 455 

§16name = "KIROV CGN "; 

eieimage = "KIR0V_1"; 

@16X = 0; ei6Y = 0 

§16Xmin = 20; @16Ymin = 25 

§16Xnax «= 620; ei6 Yinax = 455 

%CLOSEWIN, Sinitwin; 

%RETURN; 

END OBJECT 






u. COMMON.YOB 

/* 1: MOUSE instructions */ 

%FONT, "System24.fnt"; 

%WRITE, 25,25, 15/*white ltrs*//9/*lt.blue bkgnd /, 

'• Use Mouse or up/down arrow keys to hignlignt , 
•'desired selection. 


%RETURN; 
END OBJECT 


/* 2: PROCESSDOC instructions */ 

%CLEARSCREEN, ll/*lt. azure*/»* 

%FONT, "Systeia24.fnt"; 

%WRITE, 2,20, 15/*white Itrs*/,9/*green bkgnd*/, 

" Use Mouse to select the item in the picture , 
"you want to investigate. 

%WRITE, 2,470, 15/*white Itrs*/,9/*green bkgnd*/, 

" Rt.mouse button or ESC = Previous screen , 

"FI = Help F2 = Browser "; 

%RETURN; 

END OBJECT 


/* 3: INVALID SELECTION error message */ 

%DISTEXT, Serrormsgwin, 165,225, 4/*white on red*/, 
" Invalid selection; please try again. 

%WAIT,, 3.0; 

%CLOSEWIN, fiterrormsgwin; 

%RETURN; 

END OBJECT 


/* 4; EXIT confirmation */ 

%F0NT, "System72.fnt"; 

%QUESTTXTWIN, &reply, 

" ARE YOU SURE YOU WANT TO EXIT? (y/n): ", 145,225, 

l/*no.chars in reply*/, 1/*force uprcase*/, 4/*wt on red*/ 
%IF, &reply = "Y"; 


{ 


%END; 


} 

%ELSE; 
{ 


%RETURN; 

•) 

END OBJECT 


/* 5: CLOSE WINDOWS */ 
%CLOSEWIN, @presswin; 
%CLOSEWIN, @titlewin; 
%RETURN; 

END OBJECT 
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/* 6: SET VARIABLES */ 
@disdoc =1; 
@clearscreen =1; 
%RETURN; 

END OBJECT ( 
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/* set by object above */ 


V. GENERIC.YOB 
/* 1: GENERIC */ 

%IF, ©clearscreen = 1; 

^ %CLEARSCREEN, ll/*lt. azure bkgnd*/; 
iclearscreen = 0; 


%FONT, ''System24.fnt''; / 

%WRITE, 20,470, l5/*white ltrs.*/f 8/*dk.grey bkgnd*// 

•' MENU LEVEL: Main —> ", §callerobj, 

•I —> generic ^ a./ 

%IF, edisdoc =1; /* set by object above */ 

{ 

@disdoc =0; 


)/* end IF */ 

%CALL, "COMMON", 1; 

%F0NT, "Systein72. fnt"; 

%MENU, &sortvar, 183, 157, l/*default choice*// 
" LIST <whatever> SORTED BY: 

"<designator? type?>", 

"<naine?> " / 

--", 

"[return to previous menu]", 

"[exit GEOTREC]"; 

%CHOICE, Ssortvar; 


/* mouse instructions */ 


/* choice 1 */ 
/* choice 2 */ 
/* separator */ 
/* choice 4 */ 
/* choice 5 */ 


%CASE= 1: %EXECUTE, "GENERIC", 
%CASE= 2: %EXECUTE, "GENERIC", 
%CASE« 4: @clearscreen = 1; 


%EXECUTE, @callerobj 
%CASE= 5: %CALL, "COMMON", 4; 

% DEFAULT: %CALL, "COMMON", 3; 

}/* end CHOICE */ 

%EXECUTE, "GENERIC", 1; 

END OBJECT 


2 ; 

2 ; 



/* 2: Menu, SORTED BY <whatever> */ 

%IF, @clearscreen = 1; /*screen cleared except 1st time thru*/ 

^ %CLEARSCREEN, ll/*lt.azure bkgnd*/; 

%CALL, "COMMON", 1; /* mouse instructions */ 

} 

% FONT, "System2 4.fnt"; 

%WRITE, 20,470, 15/*white Itrs.*/, 8/*dk.grey bkgnd*/, 

" MENU LEVEL: Main —> ", @callerobj, 

II —> Generic —> SORT BY <whatever> "; 

%F0NT, "System72.fnt"; 

%MENU, Stchoicevar, 219,127, 5/*default choice*/, 

" <generic> ", 

" - SORTED BY <whatever> - ", 
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"[return to previous menu]”, 
"[exit GEOTREC]", 

II— 


II 

II 

II 

II. 


%FUNCTIONKEY, "ESC", 
%CHOICE, Schoicevar; 
{ 

%CASE= 2: 


"GENERIC", 2 


/* choice 2 */ 
/* choice 3 */ 
/* separator */ 
/* choice 5 */ 
/* choice 6 */ 
/* choice 7 */ 
/* separator */ 


/* "[Return to prev.menu]" */ 
%EXECUTE, "GENERIC", 1; 


%CASE= 3: /* "[Exit GEOTREC]" */ 

%CALL, "COMMON", 4; 

@clearscreen =0; 


%DEFAULT: /* all other selections */ 

%CALL, "GENERIC", 3; 

@clearscreen =1; 

)/* end CHOICE */ 

%EXECUTE, "GENERIC", 2; 

END OBJECT 


/* 3; GENERIC CHOICE */ 

%CLEARSCREEN, 0/*black*/? 

%F0NT, "System72.fnt"; 

%DISTEXT, Stempwin, 78,200, 4/*white on red*/» 

"SELECTION NOT YET AVAILABLE IN THIS PROTOTYPE APPLICATION"!! 

" II 

%WAIT,,3.0; 

%CLOSEWIN, &tempwin; 

%RETURN; 

END_OBJECT 
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w. 6E0TREC.BAT 
§echo off 
cd c:\hyperdoc 
metawndo 
hyper logon 
els 

cd c:\ 

@echo off 


X. FULCRUM.BAT 

lecho ’nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 

lecho’ GATEWAY to FULCRUM!!! 

lecho * nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 

@echo. 

@echo 
@echo 
@echo 
@echo 
@echo. 

@echo 
@echo off 
pause 

call c;\proc\restart v. • ^+. 

:RESTART is a FULCRUM batch file, and as such is not 

;provided in this Appendix 
call c:\geotrec 
@echo off 


_ If you do NOT want to start Fulcrum, 

hold CTRL key down and press c; then at 
DOS prompt [e.g., "CiV'] type "geotrec" 
and press ENTER; 

— OTHERWISE, 


y. PARADOX.BAT 

©echo 
©echo 
©echo 
©echo 
©echo 
©echo 
©echo 
©echo 
©echo 
©echo 
©echo 
©echo 
©echo 
©echo 


NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN 

GATEWAY to PARADOX!!! 

’nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 

— If you do NOT want to start Paradox 3.0, 
hold CTRL key down and press C; then at 
DOS prompt [e.g., ”C;\>"] type "geotrec" 
and press ENTER; 


— OTHERWISE, 


off 


pause 

call c:\para 
call c:\geotrec 
©echo off 
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Z. PARA.BAT 

@echo off 

path=d:; c:; c: \insdos; c: \dbases\paradox3; 
cd c:\dbases\paradox3 
paradox3 
cd c: \ 

path=d:; c:; c: \insdos; 

@echo off 

AA. INGRES.BAT 

@echo. 

§echo NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN 
§echo. 

@echo GATEWAY to the THREAT DATABASE 1!! 

@echo. 

§echo NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN 
@echo. 

@echo — If you do NOT want to start this application, 
@echo hold CTRL key down and press C; then at 

@echo DOS prompt [e.g., ''C:\>''] type "geotrec” 

@echo and press ENTER; 

§echo. 

§echo ~ OTHERWISE, 

@echo off 
pause 

call c;\threat 
call c:\geotrec 
@echo off 

AB. THREAT.BAT 

:THIS BATCH FILE SHOULD BE IN THE C: ROOT DIR, WITH INGRES 
:PROGRAMS IN C:\INGRES AND SUBDIRS \BIN, \FILES, \LIB, \TMP, 
;\DATA\{dbasename), and \ABF\{dbasename}\{applicname}. 

@echo off 

path=d:;C:;\msdos;\ingres;\ingres\bin; 

@echo off 
els 

dbms -m %1 %2 %3 %4 

run4gl threatdb c:\ingres\data\threatdb\sovietdb.img aogon 
els 

rmingres 

path=d:;c:;\msdos; 

@echo off 
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AC. HDTOOLS.BAT 
@echo. 

§ echo NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN 

@echo. 

@echo GATEWAY to HYPERDOC TOOLS!!! 

@echo. 

@ echo nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 
@ echo. 

@echo — If you do NOT want to start Hyperdoc Tools, 

@echo hold CTRL key down and press C; then at 

@echo DOS prompt [e.g., "C:\>''] type "geotrec" 

@echo and press ENTER; 

@echo. 

@echo — OTHERWISE, 

@echo off 
pause 
call c:\hd 
call c;\geotrec 
@echo off 

AD. HD.BAT 

@echo off 

cd c:\hyperdoc 

metawndo 

hdoutils 

els 

cd c;\ 

@echo off 
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